Является ли хорошей практикой хранить имена свойств в общедоступной постоянной строке?

ИМХО, всегда полезно переместить любые «магические строки» в константы.

Вы можете рассмотреть возможность использования лямбда-выражений для «выбора» ваших свойств, например:

GetDataFieldName(studentCollection => studentCollection.Count)

Вам придется реализовать GetDataFieldName самостоятельно, немного поразмыслив. Вы можете посмотреть HtmlHelperExtensions из MVC, чтобы увидеть, как это можно сделать. Это будет самый безопасный подход, который дает вам ошибки времени компиляции, когда что-то идет не так, и позволяет легко переименовывать свойства с помощью существующих инструментов рефакторинга.

С одной точки зрения: если вы используете это имя свойства несколько раз, это хорошая практика. Это наверняка поможет с рефакторингом, и когда вы, например, измените имя свойства, вы увидите, что вам также нужно изменить эту константу.

С другой точки зрения, я думаю, будет некрасиво, когда мой класс с 10 свойствами будет иметь 10 дополнительных констант. Другим решением, если вы хотите избежать констант или явного ввода имени, может быть получение имен свойств через отражение.

Использовать такой подход или нет вы должны решать сами.

Я думаю, что это обычная практика — помещать эту «магическую строку» или «магические числа» в какое-то строго типизированное хранилище.

Что-то, что вы можете рассмотреть, это закодировать его аспектно-ориентированным способом.

Например, вызовы notifypropertychagned могут быть реализованы с помощью атрибута, реализованного с помощью инфраструктуры aop, например PostSharp .

[NotifyChange]
public int Value {get;private set}

У этих инструментов также есть некоторые недостатки, но я думаю, что есть сценарии, в которых они могут сэкономить вам много работы.

Я не знаю, полностью ли я понимаю ваш вопрос, но если я правильно понимаю, я бы использовал для этого атрибут, примером может быть использование ColumnAttribute в Linq, которое вы используете для сопоставления свойства с определенным столбцом в базе данных (http://msdn.microsoft.com/en-us/library/system.data.linq.mapping.columnattribute.dbtype.aspx), как в этом примере:

[Column(Storage="ProductID", DbType="VarChar(150)", CanBeNull=False)]
public string Id { get; set; }

И я бы никогда не использовал DataFieldName, я бы привязал DataBind к строго типизированным объектам (и, конечно, также сделал бы интерфейс к классу, который использует указанное выше свойство, чтобы я мог легко изменить реализацию в будущем;))

Я предполагаю, что если имена используются во многих местах, было бы проще просто изменить их в этом одном месте и использовать константу, как описано в вашем комментарии.

Однако изменение имени столбца базы данных и имени свойства объекта подразумевает изменение вашей концептуальной модели данных. Как вы думаете, как часто это будет происходить? На ранних стадиях проекта, когда концептуальное моделирование и реализация выполняются командой разработчиков параллельно, это может быть довольно плавным, но как только начальное концептуальное моделирование выполнено (независимо от того, формализовано ли это сознательно или просто органично), это обычно довольно сложно. маловероятно, что такие фундаментальные вещи изменятся. По этой причине я думаю, что это относительно необычно, и этот метод будет продуктивным только в крайних случаях.

Абсолютно. Это хорошая идея.

Кстати, я бы сказал, что такие вещи лучше хранить в настройках приложения, потому что вы можете определить такие вещи в файле конфигурации приложения позже, переопределив эти настройки.

Делая это таким образом, вы избежите повторной компиляции, если какая-либо база данных, POCO или что-то еще изменится, и, как и в более новых версиях Visual Studio, таких как 2010, вы можете указать ему генерировать настройки с «общедоступной» доступностью, вы можете совместно использовать строго типизированные настройки с любой сборкой, которая ссылается на ту, которая их содержит.

В конце концов, я бы изменил ваш код на DataBindingSettings.StudentCountPropertyName вместо константы.

Прост в управлении, более удобен для повторного использования и удобочитаем, поскольку «вы настраиваете привязку данных с ее настройками».

Прочтите эту статью MSDN, чтобы узнать больше о настройках приложения:

• http://msdn.microsoft.com/en-us/library/a65txexh(v=VS.100).aspx