В MVC-модели кто несет ответственность за очистку входных данных?

Простой вопрос: у меня есть установка Model-View-Controller, при которой Модели получают доступ к базе данных SQL. В какой части я должен санировать / проверять на наличие искаженных входящих данных?

15.12.2008 11:58:04
Я смотрю на это так ... Ты ВСЕГДА собираешься почистить сиденье унитаза перед тем, как сесть на него, независимо от того, убрал ли человек перед тобой его после того, как он закончил.
user1228 15.12.2008 13:18:04
Правда. Однако избыточность питается циклами.
Esa 16.12.2008 14:21:15
6 ОТВЕТОВ
РЕШЕНИЕ

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

13
15.12.2008 12:14:08

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

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

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

1
15.12.2008 12:07:49
Это зависит от того, является ли проверка частью логики домена. Выполнение проверки только в контроллерах усложнит обмен контроллеров / представлений и, вероятно, приведет к дублированию кода.
Sydius 15.12.2008 12:19:34
Этот вопрос касался искаженных данных, поступающих от пользовательского ввода, который должен быть проверен в контроллере. Проверка бизнес-правил отличается и должна быть сделана в модели, думаю, я должен был быть более ясным ...
Neal Donnan 15.12.2008 12:31:21

Я склонен:

  • Поместите синтаксическую проверку в представление («это поле является числовым», «это поле является датой»). Это часто очень просто или даже подразумевается при выборе дизайна представления (например, использование выбора даты для полей даты).

  • Поместите семантическое нарушение в отдельный класс валидатора («это поле даты должно быть после этого поля даты», «оно может быть нулевым, если оно больше нуля») и вызовите валидатор из контроллера, передавая ошибки обратно в представление для отобразить.

(для моих собственных псевдо-правильных определений синтаксиса и семантики ...)

0
15.12.2008 12:08:44

Я бы сказал, что контроллер должен дезинфицировать вход.

Модель должна максимально отклоняться для хранения неверных данных.

3
15.12.2008 12:09:24
Это зависит от того, является ли проверка частью логики домена или просто частью интерфейса.
Sydius 15.12.2008 12:17:04
Я понимаю «валидацию» и «дезинфекцию» как две совершенно разные темы. Валидации просто отклоняют данные, которые не в правильном формате. Санитарная обработка означает принятие входных данных и их перевод в общий, нормальный формат (зачистки пробелов, ...). Эти изменения могут влиять или не влиять на достоверность данных.
Joachim Sauer 15.12.2008 16:42:56

Модель будет проверять правила бизнес-логики, то есть требования к длине пароля, если пользователю разрешено выполнять действие или нет.

Очевидно, что модель также должна обеспечивать безопасное взаимодействие с базой данных, чтобы SQL-инъекция была невозможна.

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

Я бы сказал, что очистка выходных данных также должна выполняться в контроллере перед передачей в представление.

1
15.12.2008 12:14:26

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

Тогда в моем домене есть проверка для таких вещей, как допустимые значения и другие бизнес-правила. Они ВСЕГДА проверяются перед сохранением или взаимодействием с отредактированным объектом.

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

1
15.12.2008 12:31:14