Лучшее место для проверки в модели / представлении / модели контроллера?

Question

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

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

Каковы преимущества?

Answer 1

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

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

• Если вы изменяете данные из представления, у вас должна быть проверена проверка.

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

• И, наконец, если у вас есть модель, изменяющая данные, у вас все равно должны быть проверки.

Единственный способ достичь этого состояния - эточтобы валидация вошла в модель.

Из-за производительности и более быстрого отклика после реализации валидаций в модели, вы должны попытаться добавить какую-то сторону клиента (JS), чтобы немедленно уведомить конечного пользователя.

Проверка всегда о данных.Почему вы проверяете данные?Таким образом, вы можете сохранить целостность информации, которую вы храните.Наличие проверок на уровне модели позволяет теоретически всегда быть правильными.Это всегда необходимость.Оттуда вы можете добавить дополнительные проверки в свою бизнес-логику и на стороне клиента, чтобы сделать ваше приложение более удобным для пользователя.

Answer 2

Если вы проверяете данные на стороне клиента (т. Е. Проверка Javascript), которых абсолютно недостаточно и совсем не безопасно, вы должны реализовать их в View.

Если вы проверяете данные на стороне сервера, и ваша проверка не требует бизнес-логики приложения (т. Е. Вы не проверяете, имеет ли пользователь достаточный кредит в своей учетной записи), вы должны выполнить проверку в контроллере.

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

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

Вы можете использовать регулярные выражения для большей части проверки, которая имеет одинаковый (почти) синтаксис в PHP и JS.

Answer 3

Проверка в модели кажется наиболее распространенным подходом (в итоге получается что-то вроде $obj->isValid()), и это подходит во многих ситуациях.

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

• Если большая часть общей проблемы проверки связана с информацией, недоступной для модели (например, если пользователь-администратор может выполнять преобразования, которые не может выполнять обычный пользователь, или определенные свойства не могут быть изменены после определенной даты), то вы можете захотеть проверить все эти ограничения в одном месте.
• Также может быть удобно или необходимо применять очень слабые правила проверки при построении объектов для тестов. (Для объекта «корзина покупок» обычно может потребоваться связанный пользователь, которому, в свою очередь, требуется действительный адрес электронной почты и т. Д. 100% действительный объект корзины покупок может быть неудобным для создания в модульных тестах корзины покупок.)
• По историческим причинам правила проверки могут измениться (например, принудительно установить «пол», если ранее ни один из них не был необходим), и поэтому вы можете получить разные версии данных, которые должны обрабатываться по-разному. (Различные правила проверки могут также применяться к массовому импорту данных.)
• Если проверка очень сложна, вы можете захотеть предоставить разные сообщения об ошибках (или их вообще нет) в зависимости от того, что наиболее полезно для вызывающего. В других ситуациях true или false могут быть всем необходимым.

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

Answer 4

Не путайте с санитарной обработкой или очисткой объявленного значения с проверкой. Вы должны получить опубликованные значения и очистить их, удалив все вредоносные элементы из значений в контроллере. Затем отправьте данные в модель для проверки ожидаемых значений или формата. Разбивая эти действия на две процедуры, снижают риск реализации вредоносного кода. Этот метод хорошо работает, если вы используете политику «не доверяйте никому»; зная, что некоторые программисты могут стать небрежными или ленивыми. Еще одна положительная сторона - предотвращение раздувания и переутомления вашей Модели, если так, то используйте помощника модели, чтобы выполнить грязную работу. Этот подход также поможет сбалансировать нагрузку на ваше приложение и повысить производительность.