Проверка должна быть на бизнес-моделях или на моделях?

Question

Я пытаюсь выяснить, где поставить проверку в моем приложении N-Tier Asp.net MVC

С одной стороны, мне кажется, что проверка должна проводиться на бизнес-уровне с самими бизнес-объектами. Это означает, что когда меняются правила валидации, мне нужно изменить их только в одном месте (например, сейчас отображаемые имена пользователей могут быть любыми, но теперь я хочу, чтобы имена были минимум 5 символов и не содержали символов). Это упрощает понимание того, где найти правила проверки, и упрощает поддержание согласованности правил проверки для всех процессов.

С другой стороны, я также чувствую, что проверка должна быть на моделях представления, потому что иногда вам требуется проверка для данных конкретного процесса, которые не потребуются для бизнес-объекта. Например, когда пользователь меняет свой пароль, вы хотите, чтобы он дважды вводил свой пароль в форме, чтобы он не ошибся в своем пароле и не смог войти в систему. Бизнес-объекту User не нужны два поля пароля, потому что это не имеет смысла, поскольку вам нужно только два пароля при смене текущего пароля (или создании новой учетной записи). Поэтому для меня имеет смысл поставить валидацию на модели представлений, чтобы убедиться, что валидация выполняется для конкретного процесса. Недостатком этого является то, что теперь, когда правила проверки меняются, у вас появляется МНОГИЕ места, которые необходимо обновить (вы должны изменить правила для каждой модели представления, имеющей дело с пользователями).

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

Answer 1

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

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

Концепция, называемая "толстыми моделями", предусматривает как можно больше проверок на бизнес-уровне, что имеет много преимуществ;

• Ваш код будет использоваться повторно, поскольку он будет заключен внутри каждого бизнес-объекта, а не для конкретных действий контроллера, например.Если вам нужно обновить бизнес-правило, то вам нужно обновить только соответствующие модели, а не каждый контроллер, который использует эти модели (вы тоже хорошо это поняли)
• Ваш код будет более переносимым, так какнапример, будет проще переключиться на другую среду, если у вас нет бизнес-уровня, который опирается на контроллеры для реализации бизнес-логики
• Контроллеры будут легче понимать, поэтому и будет понятен поток в вашем приложении.легче следовать, и новым разработчикам, вероятно, будет легче набрать скорость
• Написание правила проверки один или два раза меньше ошибок телефона, чем написание многократно
• Отладка и тестирование, вероятно,быть проще

Надеюсь, это поможет.

Answer 2

Я рекомендую ваш третий вариант. Разделите валидацию соответствующим образом.

Используя ваш пример ввода нового пароля дважды (чтобы убедиться, что он введен правильно), нет смысла отправлять оба пароля в бизнес-модель (особенно если это распределенное / веб-приложение), чтобы проверить, что они то же самое, когда ваша модель представления может легко сравнить два. Другие ограничения, такие как длина имени пользователя или обязательные поля, оставленные пустыми, могут быть легко проверены в представлении при вводе и обеспечивают немедленную обратную связь с пользователем.
Некоторые вещи нельзя проверить в модели представления, и их необходимо передать в бизнес-модель для проверки. Одним из примеров является уникальность имени пользователя.
Следует учитывать, что (особенно в веб-разработке), проверку на стороне клиента легче обойти, поэтому даже если она реализована, злонамеренный / вводящий в заблуждение пользователь все же сможет отправить неверные данные. Чтобы покрыть этот случай, лучше всего проверить любые критические ограничения проверки на стороне сервера. Конечно, это возвращает нас к не такой уж СУХОЙ проблеме, которая привела вас к этому вопросу ...

РЕДАКТИРОВАТЬ :
Основная причина, по которой я предлагаю любое разделение, состоит в том, чтобы предоставить пользователю немедленную обратную связь, чтобы он мог исправить свое представление по мере необходимости, прежде чем оно будет фактически отправлено на сервер для обработки. Если ваша дилемма находится между одним местом на стороне сервера и другим для размещения вашего кода проверки, тогда я говорю, что это вопрос личных предпочтений, но я рекомендую НЕ разделять его. В этом случае лучше всего хранить все это в одном месте, чтобы вы точно знали, куда обращаться за обновлениями и исправлениями ошибок.