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

Question

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

Answer 1

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

Я склонен:

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

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

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