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

Question

Чтобы защитить себя от сбоев из-за любого переименования свойств (допустим, вы регенерируете свои классы poco, потому что вы изменили некоторые имена столбцов в соответствующей таблице Db), рекомендуется использовать для удаления константных строк, сохраняющих свойство имена внутри?

public const string StudentCountPropertyName = "StudentCount";
public int StudentCount {get;set;}

Например: подумайте о привязке данных; где вы явно вводите имя свойства в атрибуте DataFieldName.

Или это не очень хорошая идея, и есть лучший и еще более безопасный способ?

Answer 1

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

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

GetDataFieldName(studentCollection => studentCollection.Count)

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

Answer 2

Я не знаю, полностью ли я понимаю ваш вопрос, но если я правильно понимаю, я бы использовал для этого атрибут, примером может быть использование 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 к строго типизированным объектам (и, конечно, также сделал бы интерфейс для класса, который используетсвойство выше, поэтому я легко могу изменить реализацию в будущем;))

Answer 3

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

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

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

Answer 6

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

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