Аннотации данных и MVC 1: 1 ViewModel

Question

При разработке в ASP.NET MVC я использую установку ViewModel 1: 1, где viewmodel содержит только данные, требуемые представлением. Я также использую аннотации данных для проверки на модели представления.

Меня беспокоит то, что это не соответствует принципу СУХОЙ, так как мне приходится дублировать валидацию на всех моих сайтах. Я бы хотел, чтобы проверка была в одном месте (моя модель домена), но, поскольку я никогда не отправляю модель домена в модель представления, это невозможно.

Мне было интересно, сталкивался ли кто-нибудь еще с этой проблемой и нашел подходящий способ обойти ее или есть лучшее решение?

Answer 1

У нас были аналогичные проблемы, когда мы приняли подход ViewModel 1: 1. Мы обнаружили, что 1) дублирование меньше, чем кажется на первый взгляд, и 2) что общая ремонтопригодность и мощность приложения настолько улучшены, что любые не-СУХИЕ затраты стоят своей цены.

В итоге мы подумали о проверке моделей ViewModel и предметной области с разных точек зрения (разделение проблем). При реализации проверки на модели уровня домена мы ищем комплексную защиту для предотвращения атак. Мы также обнаруживаем серьезные нарушения "контракта", которые указывают на ошибки в верхних слоях. При реализации проверки в модели представления мы строго заинтересованы в удобстве использования.

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

1: 1 ViewModels также значительно облегчает тестирование. Тесты для ViewModel могут быть написаны независимо от уровня домена, что делает модульные тесты более легкими, более удобными в обслуживании и в целом более полезными. Аналогично, вы можете протестировать модель предметной области без ментальных искажений того, как входные данные проходят через пользовательский интерфейс. Это также соответствует принципу "глубокоэшелонированной защиты".

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

Наконец, если вы предполагаете наличие слоя веб-сервисов, вы обнаружите, что разделение домена и просмотр моделей приносят дивиденды. Без этого модель предметной области неизбежно будет написана для поддержки пользовательского интерфейса. При наложении слоя на интерфейс сервиса вы обнаружите несоответствие импеданса.

Если в итоге получится значительное дублирование, вы всегда можете выделить валидацию отдельно. По нашему опыту, это не стоило того по всем причинам, рассмотренным выше.