Когда я работал над проектом веб-сайта asp.net mvc, я исследовал различные подходы к валидации. Некоторые из них были валидацией DataAnotation и блоком валидации. Они используют атрибуты для настройки правил проверки. Как это:
[Required]
public string Name {get;set;}
Меня смутило, как этот подход сочетается с SRP (принципом единой ответственности) из мира ООП. Также мне не нравится какая-либо бизнес-логика в бизнес-объектах, я предпочитаю модель «плохих бизнес-объектов», но когда я украшаю свои бизнес-объекты атрибутами проверки для реальных требований, они становятся некрасивыми (имеет много атрибутов / с логикой локализации и скоро).
Идея с атрибутами действительно проста, но, на мой взгляд, оформление валидации должно быть отделено от объекта. Я не уверен, что это подход к разделению правил проверки для XML-файлов или других объектов, возможно, это решение.
Еще одна плохая сторона АОП - проблемы с юнит-тестированием в таком коде. Когда я украсил некоторые действия контроллера пользовательскими атрибутами, например, чтобы импортировать / экспортировать TempData между действиями или инициализировать некоторые требуемые сервисы, я не смог написать надлежащий модульный тест для тестирования этих действий.
Вы думаете, что атрибуты не нарушают srp, или вы просто игнорируете это и думаете, что это самый простой, не худший способ?
P.S. Я читаю несколько подобных статей и обсуждений, и я просто хочу навести порядок.
P.P.S. извините за мой "свободный" английский: =)
EDIT
Я думаю, что «нарушающие правила» и некрасивые будут в таком сценарии:
В случае, когда у проверки есть некоторые бизнес-правила - например, пользователи должны иметь уникальную электронную почту в системе, вы должны проверить пользовательский ввод и выбросить все слои в приложение, поэтому, когда вы пишете свой пользовательский атрибут для проверки этих данных, бизнес-объект будет связан с ваш атрибут броска слоя данных.