Рекомендации по предотвращению дублирования логики проверки при работе как с объектами домена, так и с моделями представления в ASP.NET MVC

Question

Общий сценарий:

Иерархическая модель предметной области сопоставляется с моделью плоского представления для целей представления.

У меня есть полная настройка проверки в моем домене, и я хотел бы избежать сопоставления модели представления с объектом домена, просто чтобы выяснить, что какое-то свойство недопустимо. Также я не хочу дублировать мою логику проверки в моих моделях представления.

Какие здесь есть хорошие практики?

Я против интерфейсов как для моделей представлений, так и для доменных объектов, поскольку модели представлений обычно строковые и плоские, тогда как объекты домена часто являются вложенными и имеют много других типов данных для свойств.

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

Но для простоты я склоняюсь к такому подходу:

Проверка на стороне сервера происходит только в доменной модели; модели представления не проверяются, но данные проверяются на клиенте с помощью JavaScript. Таким образом, в большинстве случаев мои модели представлений будут действительными, а логика проверки останется в одном месте и будет происходить только в модели предметной области. Недостатком этого подхода является то, что проверка asp.net mvc 2 не сможет его поддерживать. Что ты думаешь?

Спасибо.

Answer 1

Библиотека Microsoft Enterprise предлагает такую ​​библиотеку «Pluggable Validation», которая основана на обобщениях, если память служит.

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

Я ни в коем случае не эксперт в этой области, но я твердо убежден в том, что данные должны быть проверены непосредственно перед тем, как вы захотите что-то с ними сделать, и ВСЕГДА перед передачей в хранилище. Поэтому лучшее место для вашей логики валидации - это уровень бизнес-логики. Проверка на стороне клиента, хотя и приятна для пользователя, делает обслуживание кода кошмаром, а также приводит к дублированию кода, что может вызвать проблемы в дальнейшем.

Ваши объекты презентации должны, по моему мнению, быть DTO. Когда пользователь отправляет данные обратно на ваши контроллеры (и BLL), вы можете использовать анализаторы для преобразования объектов презентации в бизнес-объекты, которые затем могут быть проверены.

Я рекомендую прочесть блог Руди Лаковары (он же Angry .NET Developer). Он очень скромный парень с множеством хороших слов, чтобы сказать о таких вещах.

НТН

Answer 2

Не существует подхода к проверке, который бы подходил всегда .

В вашем случае, я бы использовал проверку mvc2 (с проверкой клиента) и вернулся бы к проверке домена, если проверка viewmodel прошла.

Answer 3

Мне нравится идея подключаемых / инъецируемых валидаторов. Именно так я обычно провожу валидацию (не важно, веб-формы, mvc, wpf и т. Д.). Зачем? Потому что правила валидации имеют тенденцию различаться в зависимости от сценария и уровня приложения. Пример. В вашей модели представления могут быть определенные правила проверки, связанные с макетом пользовательского интерфейса, а не с правилами домена или инфраструктуры. Если вы сделаете правила и валидаторы составными, вы можете повторно использовать многие из правил ограничения данных в каждом уровне / сценарии.

Хотя я думаю, что проверка Javascript делает вещи быстрыми для пользователя, я бы опасался использовать только javascript в ВМ.