Должна ли валидация выполняться в объектах формы или модели?

Question

Этот вопрос в основном направлен на Zend в PHP, хотя он, безусловно, относится к другим языкам и фреймворкам, поэтому я приветствую мнение каждого.

Я только недавно использовал фреймворк Zend, и хотя он не идеален, я неплохо провел время с ним. Одна вещь, которая сводит меня с ума, однако, это то, что большинство примеров, которые я вижу, что люди, использующие Zend, делают v alidation в объектах специальной формы , а не в модели. Я думаю, что это плохая практика, потому что данные могут входить в систему другими способами, помимо ввода формы, что означает, что либо валидаторы должны быть согнуты и искривлены для проверки другого ввода, либо валидация должна быть выполнена во-вторых, а логика дублирована.

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

Как я уже сказал, это в основном относится к Zend, хотя я думаю, что важно взглянуть на проблему в целом, а не работать в рамках Zend Framework, так как Zend был разработан так, чтобы вы могли использовать как можно больше, или так мало, как ты хотел.

Answer 1

Возможно, вам стоит взглянуть на Использование Zend_Form в ваших моделях от Мэтью Вейер О'Финни - один из ведущих разработчиков Zend Framework - за его взгляд на этот вопрос.

Answer 2

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

Проблема с проверкой только в представлении заключается в том, что в какой-то момент вам, вероятно, понадобится другое представление ваших данных. Ваш сайт может стать популярным, и клиенты просят API на основе XML для создания своих собственных представлений. Затем вы полагаетесь на клиента для проверки данных?

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

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

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

Answer 3

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

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

Но ничего из этого не имеет отношения к проверке данных для вставки базы данных, потому что вы не собираетесь хранить пароли в виде простого текста - вы собираетесь каким-то образом хранить их хэш (md5, md5 + salt, без разницы). Вместо этого вы можете убедиться, что у вас есть шестнадцатеричная строка из 32 символов, так что вполне вероятно, что это будет правильно созданный хэш MD5.

Этот пример пароля не единственный сценарий, просто хороший пример для объяснения здесь в этой теме.

Так, каков ответ? Я не думаю, что есть какое-то одно решение для всех. Иногда вам захочется (нужно?) Проверить данные дважды. Иногда вы будете делать это только один раз в модели. Просто сопоставьте его как можно лучше с потребностями вашего приложения.

Answer 4

Ну, проверка может быть проведена на многих разных уровнях, и обычно ни один из них не является «лучшим». Конечно, модель может быть заполнена недействительными данными, которые не приходят из формы, но мы также можем создавать формы, данные которых не попадают ни в одну модель.

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

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

Answer 5

Пример пароля Питера Бэйли отличный. Пользовательская модель может проверять, только если был установлен пароль (поскольку он хранится не в виде простого текста, а в виде хэша), а проверка ввода может гарантировать, что исходный пароль в виде простого текста соответствует требованиям безопасности (количество символов, ... ). Следовательно, вам необходимо: проверка модели и проверка формы / ввода, в идеале как отдельный, повторно используемый компонент, а не непосредственно в раздутых действиях контроллера.

Думайте о проверке входных данных как о проверке белого списка («принять заведомо хорошее»), а о проверке модели как о проверке черного списка («отклонение заведомо плохого»). Проверка в белом списке более безопасна, в то время как проверка в черном списке предотвращает чрезмерное ограничение уровня модели слишком специфическими случаями использования.

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

Смотри также: https://lastzero.net/2015/11/form-validation-vs-model-validation/

Answer 6

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

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

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

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

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

Answer 7

Как насчет размещения эстетической проверки в форме и проверки бизнес-правил в модели.

Возьмите регистрационную форму, например.

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

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

Обычно я их разделяю.

Answer 8

Я не знаю о Зенде. Но.

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

Лучшее, что вы можете сделать на стороне своей модели, - это вызвать «Утверждения» для всех данных, чтобы быть уверенным в том, что во время разработки будет проведена валидация.

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