Где лучшее место для проверки данных формы?

Question

Вопрос прост. Где я должен поместить процесс проверки формы в шаблон проектирования MVC (Zend, Symphony, Cakephp, Codeigniter). Я задаю этот вопрос, потому что у меня есть своя собственная структура. Но я не могу решить, где мне обращаться с проверкой формы. Например, я могу написать операторы if в контроллере, но это делает контроллер "толстым", или я могу добавить операторы проверки в функцию модели (в User :: register (,,)). Конечно, это не очень сложная вещь, но моя цель - понять, как они работают в приложениях уровня предприятия.

Answer 1

Если вы рассматриваете Модели в MVC как то, что мы в мире .NET называем ViewModels (и я считаю, что в других местах они называются Презентационными моделями) вместо Моделей домена, Модель будет отличным местом для добавления проверки / подтверждения. *

Это позволит вам повторно использовать логику проверки везде, где вы повторно используете Модель, и это имеет смысл, поскольку Модель будет инкапсулировать логику проверки вместе с данными. Это звучит как высокая сплоченность для меня.

Как проверка работоспособности, ASP.NET MVC, похоже, движется в этом направлении. Поскольку вопрос помечен как «php», я не уверен, что этот последний фрагмент информации усиливает или ослабляет аргумент.

Answer 2

Проверка - контроль ввода. MVC означает Model View Controller, поэтому проверка должна выполняться в контроллере.

Общие проверки, такие как isInt (), isStr (), isEmailAddress, isFloat () и т. Д. И т. Д. Могут / должны быть помещены в базовый контроллер. Тогда у вас могут быть субконтроллеры для указанных моделей (привязка к вашей базе данных). Эти субконтроллеры затем выходят из базового контроллера.

Answer 3

Есть несколько мест, где может произойти проверка.

Во-первых, на стороне клиента и на стороне сервера: часто рекомендуется выполнить предварительную проверку на стороне клиента (например, «разрешено только число!») Перед отправкой битов по проводам. Проверка на стороне сервера всегда является обязательной в качестве требования безопасности / целостности данных.

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