Есть ли причины не использовать пользовательские атрибуты?

Question

Это в основном запрос комментариев, если есть причина, по которой я должен не идти по этому пути.

У меня есть многоуровневое приложение, созданное CodeSmith. На уровне пользовательского интерфейса должны быть некоторые обязательные поля, и обязательные поля будут различаться в зависимости от значений полей в связанном объекте. То, что я думаю сделать, это добавить CustomAttribute PropertyRequired к каждому свойству в сущностях, которые я могу установить в значение true или false, когда загружаю сущность в ее менеджер. Затем я буду использовать Reflection для запроса свойства и визуальной обратной связи с пользователем на уровне пользовательского интерфейса, и я могу проверить, что все необходимые свойства имеют действительное значение в диспетчере перед сохранением. Я разработал это как доказательство концепции с одним свойством в одном объекте, но прежде чем я попытаюсь распространить его на остальную часть приложения, я хотел бы спросить, есть ли кто-то с большим опытом, чтобы сказать мне идти за это, или почему мне не понравится, когда я увеличу масштаб. Если это плохая идея или если вы можете предложить лучший подход, пожалуйста, выскажите свое мнение.

Answer 1

Это довольно разумный способ сделать это (я делал что-то очень похожее раньше), но есть всегда недостатков:

• любому коду, нуждающемуся в сущности, потребуется дополнительная ссылка (при условии, что атрибут и сущность находятся в разных сборках)
• значения (если вы не умны с этим) должны быть определены во время компиляции
• вы не можете использовать его на объектах вне вашего контроля

В большинстве случаев вышеизложенное не является проблемой. Если они являются проблемой, возможно, вы захотите поддержать модель внешних метаданных - но , если вам это не нужно, это будет избыточным. Не делайте этого, если только вы не обязаны (имеется в виду: используйте атрибуты; они обычно в порядке).

Answer 2

Нет внутренней причины избегать пользовательских атрибутов. Это поддерживаемая функция CLR, которая является основой для многих доступных продуктов (Code Contracts, FxCop и т. Д.).

Answer 3

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

• Вы тесно связываете бизнес-логику с самим бизнес-объектом. Существуют ли обстоятельства, при которых обязательное поле или действительные значения могут измениться? Возможно, вы ограничиваете себя или столкнулись с несовместимым механизмом проверки
• Динамическое присвоение возможно, но более сложно - то есть, когда вы устанавливаете поле, обязательное для заполнения, оно будет таким, если вы не переопределите
• Пользовательские атрибуты могут быть довольно негибкими, если в дальнейшем вы захотите сделать что-то более сложное, а именно, если вам нужно передать состояние в управляемую атрибутом схему проверки. Атрибуты, такие как декларативное присваивание. Только наличие истинного / ложного обязательного свойства здесь не должно быть проблемой, хотя

Будучи просто защитником дьяволов, в общем, для довольно простого приложения, где вас интересуют только обязательные поля, это довольно аккуратный способ сделать это