Я работаю над проектом PHP, который широко использует шаблон проектирования MVC. Я хочу добавить валидацию в форму, и мне интересно, какое правильное место для проверки.
Из-за того, как формируются формы, валидация на данных обратной передачи намного проще и менее повторяется с точки зрения компонентов. Допустимо ли иметь представление, подтверждающее данные ответа, или это должно быть реализовано внутри контроллера или даже модели?
Каковы преимущества?
Если вы проверяете данные на стороне клиента (например, проверку Javascript), которая абсолютно не достаточна и не защищена вообще, ее следует реализовать в представлении.
Если вы проверяете данные на стороне сервера, и ваша проверка не требует бизнес-логики приложения (т. Е. Вы не проверяете, имеет ли пользователь достаточный кредит в своей учетной записи), вы должны проверить его в контроллере.
Если для проверки требуется бизнес-логика, выполните ее внутри модели и вызовите ее через контроллер.
Проверка обратной обратной связи не является хорошей, поскольку она создает много давления и задержки. И единственное преимущество заключается в том, что программист (не учитывается).
Вы можете использовать регулярное выражение для большей части проверки, которая имеет тот же синтаксис (почти) на PHP и JS.
Правильное место для проверки – это Модель .
Это имеет наибольший смысл, потому что вы выполняете проверку данных, что представляет собой модель. Что касается обновлений CRUD, модель всегда должна использоваться как-то.
Если вы меняете данные из представления, вы должны проверить проверки.
Если у вас есть контроллеры, изменяющие данные, вы должны проверить проверки.
И, наконец, если у вас есть сама модель, меняющая данные, вы все равно должны иметь проверки.
Единственный способ добиться этого состояния состоит в том, чтобы пройти валидацию в модель.
Из-за производительности и более быстрого ответа после реализации валидаций в модели вы должны попытаться добавить какую-то клиентскую сторону (JS), чтобы немедленно уведомить конечного пользователя.
Валидация всегда относится к данным. Почему вы проверяете данные? Таким образом, вы можете сохранить целостность информации, которую вы храните. Наличие валидаций на уровне модели позволяет теоретически всегда быть правильными. Это всегда необходимо. Оттуда вы можете добавить дополнительные проверки в своей бизнес-логике и на стороне клиента, чтобы сделать ваше приложение более удобным для пользователя.
Валидация в модели, по-видимому, является наиболее распространенным подходом (в итоге вы $obj->isValid() что-то вроде $obj->isValid() ), и это подходит во многих ситуациях.
Однако, в зависимости от вашего варианта использования, могут быть веские причины для выполнения проверки вне модели, либо с использованием отдельного кода проверки, либо в контроллере и т. Д .:
true или false может быть все, что необходимо. Возможно использование этих различных вариантов использования посредством аргументов метода isValid() модели, но это становится все более громоздким по мере увеличения количества стилей проверки. (И я действительно думаю, что почти гарантировано, что единственный метод «один размер подходит всем» isValid() конечном итоге окажется недостаточным для большинства нетривиальных проектов.)
Не путайте с дезинфекцией или очисткой опубликованного значения с помощью проверки. Вы должны получить опубликованные значения и счистить их, удалив любые вредоносные элементы из значений в контроллере. Затем отправьте данные в Модель для проверки на ожидаемые значения или формат. Разбирая эти действия на две процедуры, вы уменьшаете риск появления вредоносного кода. Этот метод работает хорошо, если вы используете политику «доверие никому»; зная, что некоторые программисты могут стать неаккуратными или ленивыми. Другая положительная сторона мешает вашей модели стать раздутой и переработанной, если это так, то используйте вспомогательную модель для выполнения грязной работы. Этот подход также поможет сбалансировать нагрузку на приложение и повысить производительность.