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

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

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

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

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

4 голоса | спросил pencilCake 14 J000000Thursday11 2011, 10:12:32

6 ответов


0

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

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

GetDataFieldName(studentCollection => studentCollection.Count)

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

ответил Jakub Konecki 14 J000000Thursday11 2011, 10:30:24
0

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

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

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

ответил Andrew Orsich 14 J000000Thursday11 2011, 10:28:47
0

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

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

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

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

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

ответил Boas Enkler 14 J000000Thursday11 2011, 10:35:55
0

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

ответил Martin Odhelius 14 J000000Thursday11 2011, 11:45:32
0

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

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

ответил Adam Ralph 14 J000000Thursday11 2011, 10:37:15
0

Совершенно верно. Это хорошая идея.

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

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

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

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

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

ответил Matías Fidemraizer 14 J000000Thursday11 2011, 11:30:34

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132