#validation #domain-driven-design
#проверка #дизайн, управляемый доменом
Вопрос:
Одна вещь, которая меня смущает в отношении DDD, заключается в том, что наш домен должен обрабатывать всю бизнес-логику и применять инварианты. Я заметил, что некоторые люди (включая меня) обрабатывают определенные инварианты на уровне представления (т. Е. Веб-формы, представления и т.д.) С помощью javascript. В основном это делается для повышения производительности, чтобы сервер не выполнял каждый запрос, который может оказаться недействительным.
Даже при том, что этот подход может быть выгодным с точки зрения производительности, он нарушает принципы DDD. Что, если бизнес-правила будут изменены? Таким образом, у нас нет расширенного домена, где фиксируются все бизнес-правила. В случае изменения мы должны изменить домен, а также уровень представления.
Кто-нибудь сталкивался с такой ситуацией раньше?
Я хотел бы знать ваши мысли по этому поводу.
Приветствия,
Mosh
Ответ №1:
Одним из фреймворков, который поддерживает DRY и проверку как на стороне сервера, так и на стороне клиента, является ASP.NET MVC 2.
Это делается путем генерации JavaScript на основе правил модели, который отправляется клиенту.
Подробнее об этом можно прочитать здесь: http://weblogs.asp.net/scottgu/archive/2010/01/15/asp-net-mvc-2-model-validation.aspx
Комментарии:
1. Я знаю о функциях проверки в ASP.NET MVC 2. Однако то, что я имею в виду здесь, — это более сложные правила проверки. Например: если установлен какой-либо флажок, а в список не добавлены элементы, то отобразите какое-либо сообщение. Это нечто большее, чем проверка полей ввода на соответствие null или диапазону данных и т.д.
2. Если вы хотите, чтобы ваш код был сухим и решал сложные задачи проверки модели на стороне клиента, я предлагаю вам разрешить вашим сущностям находиться в недопустимых состояниях и попросить их сообщать о недопустимом (я часто использую какую-нибудь коллекцию BrokenRule). Затем ваш контроллер / Presenter / ViewModel использует эту информацию для соответствующего обновления представления.