DDD, viewmodel и проверка в ASP.NET MVC

Question

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

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

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

Теперь я сталкиваюсь с ситуацией, когда я хочу прикрепить некоторые правила проверки.
Я думал, что мог бы присоединить правила проверки (с DataAnnotations) к сущностям, но это не может работать, если я использую модель представления.

Вот вопросы:

• Следуетпроверка не является частью модели предметной области?
• Разве не требуется много времени для создания модели, а затем тратить время на переназначение тех же полей (свойств) в модели представления?
• Разве это не анемичная модель, если в ней нет, по крайней мере, правил валидации?Я начинаю задаваться вопросом, действительно ли DDD действительно подходит для приложений малого / среднего размера.

Я ценю любую помощь / предложение.

Answer 1

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

Answer 2

Разве проверка не должна быть частью модели предметной области?

Я думаю, что это должно быть как для модели предметной области, так и для моделей представления.Проверка в моделях представления проверит правильность ввода для типа --datetime, decimal, int и т. Д., В то время как проверка в модели предметной области должна проверить правила, специфичные для приложения.Таким образом, даже если вы решите использовать другой пользовательский интерфейс, проверка бизнеса будет по-прежнему на месте, в то время как пользовательский интерфейс должен будет позаботиться о проверке входных данных.модель, а затем потратить время на переназначение тех же полей (свойств) в модели представления?

Существуют инструменты, которые могут помочь вам в этом, например, automapper в коде.По моему мнению, это приводит к более чистому разделению между BLL и пользовательским интерфейсом.

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