Этот вопрос в основном ориентирован на Zend в PHP, хотя он, безусловно, относится к другим языкам и структурам, поэтому я приветствую мнение каждого.
Я только недавно использовал фреймворк Zend, и хотя он не идеален, у меня было довольно хорошее время с ним. Однако одна вещь, которая сводит меня с ума, заключается в том, что большинство примеров, которые я вижу для людей, использующих Zend, делают алиадирование в специальных объектах формы , а не в модели. Я думаю, что это плохая практика, потому что данные могут войти в систему другими способами помимо ввода формы, а это значит, что либо валидаторы должны быть согнуты и скручены, чтобы проверить другой вход, либо валидация должна быть выполнена на втором месте, а логическое дублирование.
Я нашел некоторые другие сообщения и блоги там с людьми, которые чувствуют то же самое, что и я, но разработчики Zend сделали этот выбор по какой-то причине, и другие люди, похоже, используют его без проблем, поэтому я хотел получить некоторую обратную связь от сообщества здесь.
Как я уже сказал, это в основном относится к Zend, хотя я думаю, что важно рассматривать проблему в целом, а не работать в рамках структуры Zend, поскольку Zend был разработан так, чтобы вы могли использовать столько или как мало , как вы хотели.
Это неопределенный ответ, но я считаю, что модель должна отвечать за достоверность своих собственных данных. Если это так, то валидация принадлежит модели, однако это может не всегда достижимо, и может потребоваться выполнить проверку в представлении, однако я думаю, что это должно быть в дополнение к проверке, выполняемой в модели, а не замене для этого.
Проблема только с проверкой в представлении заключается в том, что в какой-то момент вам, вероятно, понадобится другое представление ваших данных. Ваш сайт может стать популярным, и клиенты просят API на основе XML генерировать свои собственные представления. Затем вы полагаетесь на клиента для проверки данных?
Даже если вам не нужно предоставлять API-интерфейсы, некоторые клиенты могут захотеть, чтобы настроенные представления были достаточно разными, чтобы гарантировать совершенно другую версию страницы, и теперь у вас есть подтверждение в дублированных представлениях.
Я думаю, что идеальным сценарием является то, что ваша модель проведет проверку, но чтобы результаты проверки были доступны для просмотра, чтобы прочитать и снова отобразить страницу с результатами проверки.
Я думаю, что вполне разумно иметь представление о проверке, если вы хотите мгновенно отображать данные проверки для пользователя и т. Д., Но окончательное решение о достоверности данных должно быть оставлено с моделью.
Важно помнить, что проверка данных, относящаяся к приложению, не всегда совпадает с проверкой данных, относящейся к схеме базы данных.
Рассмотрим простую регистрационную форму, в которой пользователь создает учетную запись с именем пользователя и паролем. Вы выполняете проверку пароля, потому что хотите, чтобы это было X количество символов в длине и содержало хорошее сочетание типов символов (или что-то еще).
Но ничто из этого не имеет отношения к проверке данных для вставки базы данных, потому что вы не собираетесь хранить текстовые пароли – вы собираетесь каким-то образом сохранить хэш из них (md5, md5 + salt, что угодно). Вместо этого вы можете убедиться, что у вас есть шестнадцатеричная строка с 32 символами, так что она, скорее всего, будет правильно создана хэш MD5.
Этот пример пароля не является единственным сценарием, просто хорошим для объяснения здесь в этом разделе.
Так в чем же ответ? Я не думаю, что есть какие-то одноразовые решения. Иногда вам нужно (нужно?) Дважды проверить данные. Иногда вы будете делать это только один раз в Модели. Просто сравните его как можно лучше с потребностями вашего приложения.
Возможно, вам стоит взглянуть на использование Zend_Form в ваших моделях Мэтью Вейера О'Финни – одного из ведущих разработчиков Zend Framework – для его взгляда на этот вопрос.
Ну, валидация может быть выполнена на разных уровнях, и обычно ни один из них не является «лучшим». Конечно, модель может быть заполнена недействительными данными, которые не поступают из формы, но мы также можем создавать формы, данные которых не попадают ни в какую модель.
Более того, прямая валидация в моделях не интегрирована с нашей системой рендеринга форм, что вызывает проблемы, если мы хотим показать сообщения об ошибках и повторно заполнить форму с введенными пользователем данными.
Оба решения имеют свои плюсы и минусы. Было бы идеально иметь систему, которая гарантирует, что окончательная проверка должна быть выполнена на некотором уровне. Если форма не проверяет некоторые данные, то модель делает и наоборот. К сожалению, я не слышал о такой библиотеке, но должен отметить, что валидаторы в инфраструктуре не зависят от источника. Вы можете передать данные POST им, но то же самое можно сделать с информацией, полученной из правильно проанализированных CSV, баз данных MYSQL и т. Д.
Я не знаю о Зенде. Но.
Ваша модель должна получать достоверные данные. Модель и ее методы не должны проверять данные снова и снова. Конечно, должны быть функции, которые выполняют фактическую проверку, и их следует вызывать из проверки gui или из другого места ввода данных.
Лучшее, что вы можете сделать на стороне вашей модели, – это «Утверждения» во всех данных, чтобы убедиться в том, что время разработки было принято.
Более низкий уровень кода (UI, model, utils) должен содержать меньше кода проверки и проверки. Как тогда есть большая вероятность того, что одна и та же валидация будет называться более одной.
Как насчет того, чтобы провести эстетическую валидацию в форме и валидацию бизнес-правил в модели.
Возьмите регистрационную форму, например.
Форма будет гарантировать, что поле электронной почты обрезается и содержит действительное электронное письмо, что поле пароля / подтверждения пароля идентично и что пользователь установил флажок Я согласен с условиями.
Модель регистрации позволит убедиться, что письмо еще не было принято в таблице, соль и хэш-пароль.
Это то, как я обычно разделяю два.
Пользовательский ввод должен быть проверен, когда он вводится, поскольку он специфичен для формы записи (т. Е. Выполняет некоторую проверку формы), убедитесь, что текстовые поля, которые должны иметь номера, являются номерами).
Бизнес-логика, вероятно, должна быть проверена на модели, потому что она специфична для модели (т. Е. Убедитесь, что они уже зарезервировали ту же самую комнату или что-то в этом роде).
Проблема с его проверкой на уровне модели заключается в том, что модель может использоваться по-разному. Правильный ввод для одного сценария может быть неправильным для другого.
Другая проблема заключается в том, что вы обычно нуждаетесь в некоторой проверке контекста, например, при отображении красного блока вокруг элемента управления формы, который имеет плохой ввод.
Модель или база данных могут выполнить некоторую дополнительную проверку, чтобы убедиться, что код пользователя не делает что-то совершенно неправильное (ограничения и т. Д.).
Пример пароля Питера Бэйли превосходный. Пользовательская модель может проверять только, если был установлен пароль (поскольку он не хранится как обычный текст, а как хэш), в то время как проверка ввода может гарантировать, что исходный пароль обычного текста соответствует требованиям безопасности (количество символов, … ). Поэтому вам нужны оба: проверка модели и валидация формы / ввода, в идеале как отдельный компонент многократного использования, а не непосредственно в раздутых действиях контроллера.
Подумайте о проверке входных данных как валидацию белого списка («принять известное добро») и подтверждение модели в качестве проверки черного списка («отвергнуть известный плохой»). Валидация белого списка более безопасна, в то время как проверка черного списка предотвращает чрезмерное ограничение вашего модельного слоя до очень конкретных вариантов использования.
Недопустимые данные модели всегда должны вызывать исключение (в противном случае приложение может продолжать работать, не замечая ошибки), в то время как недопустимые входные значения, поступающие из внешних источников, не являются неожиданными, но довольно распространенными (если только у вас нет пользователей, которые никогда не ошибаются).
См. Также: https://lastzero.net/2015/11/form-validation-vs-model-validation/