Zend Framework: что такое правильное место для проверки ввода пользователя?

Question

Я хочу добавить пользователя в таблицу пользователей по ссылке типа '/ index / adduser / id / 7'.

Вопрос

Должен ли я проверять пользовательский ввод внутри функции 'adduserAction' внутри контроллера или где-то внутри файла модели? Я поместил файлы, содержащие функции, связанные с базой данных, в каталог 'models'. Предположим, что пользователь добавлен в таблицу через 'id'. Этот идентификатор отправляется через «get». И, наконец, его добавление в таблицу с помощью функции AddUser (внутри файла модели). Затем я должен проверить этот «id» внутри «adduserAction» или «AddUser». С точки зрения масштабируемости, было бы лучше сделать это внутри AddUser?

Answer 1

Существует популярная парадигма веры, которая гласит:

Тонкие контроллеры, толстые модели.

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

Я считаю, что среди программистов .NET следующая установка (или что-то подобное) является довольно распространенной практикой (если масштаб проекта подтверждает это):

Controller
  -> ServiceLayer
     -> Repository
        -> DataObject

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

Термин Модель - это несколько расплывчатый термин. В приведенном выше примере вы можете рассматривать три последних слоя как слой модели. Эти три слоя представляют собой следующее:

• ServiceLayer
  Ответственный за бизнес-логику. Другими словами: извлечение объектов данных (моделей) из репозитория, связывание моделей вместе, И проверка моделей перед их сохранением , отправка почты пользователю и т. Д.
• Репозиторий
  Механизм персистентности некоторого типа (например, база данных), который обслуживает объекты DataObject для уровня обслуживания и сохраняет объекты DataObject обратно в механизме сохранения ( после того, как уровень сервиса их подтвердил )
• DataObject
  Вы можете считать это актуальными моделями. Предпочтительно объекты DataObject имеют общие интерфейсы (независимые от репозитория, то есть), так что репозитории взаимозаменяемы. Другими словами, когда хранилище изменяется из базы данных в XML-файл из какого-либо веб-сервиса, DataObject по-прежнему имеет тот же интерфейс, что и сервисный уровень, и в конечном итоге представление может работать с ним.

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

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

Answer 2

Я бы сказал, поставьте проверку в вашей модели. Затем вы можете сохранить свои правила проверки в центральном месте. Как ваш контроллер должен знать точную длину действительного имени пользователя? Это модельная территория. Ваш контроллер может спросить модель, правильна ли длина имени пользователя или нет, но само правило должно быть в вашей модели. В моем контроллере я бы сделал что-то вроде этого:

$ модель = новая модель; $ model-> loadFromArray (что-то, чтобы получить сообщение); if (! $ model-> isValid ()) {переслать обратно в форму} $ Модели-> Save ();

Answer 3

идеальным решением является использование проверки в ваших формах - т.е. добавление ее к вашим zend_form_elements - см. http://framework.zend.com/manual/en/zend.form.elements.html

Answer 4

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

• Я использую формы для проверки входных данных и фильтрации Выполните проверку в моделях

• У меня есть метод проверки, который проксиметод проверки формы.

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

Вот краткий пример:

//UserModel
class Default_Model_User
{

    protected $_form;

    public function getForm()
    {
        if(!isset($this->_form)) {
            $this->_form = new Default_Model_Form_User();
        }
    }

    public function validate($data)
    {
        if($result = $this->getForm()->isValid($data)) {
        // if you have custom validation conditions outside of the form, then you 
        // can do the validation here also.
            if($data['controller_entered'] == 'some value') {
                $result = false;
            }
        }
    return $result;
    }

    public function saveUser($data)
    {
        if($result = $this->validate($data)) {
            // do something.
        }
    return $result;
    }
}

Если вы еще не читали его, обязательно ознакомьтесь с книгой Surviving The Deepend, свободно доступной по следующему адресу:URL:

http://www.survivethedeepend.com/zendframeworkbook/en/1.0

Эта глава относится к вашей дилемме: http://www.survivethedeepend.com/zendframeworkbook/en/1.0/implementing.the.domain.model.entries.and.authors#id1491270

Вы, несомненно, столкнетесь с другими проблемами по мере прохождения ... Этоможет помочь проверить комментарии к моему посту в блоге относительно слоя модели, где я освещаю эту проблему: http://www.rvdavid.net/my-zend-framework-model-layer-part-service-part-orm/

Надеюсь, это кому-нибудь поможет.

Answer 5

Я бы сделал это в контроллере, а не в модели. ИМХО, это лучшее место, потому что тогда очищенные данные уже безопасны для использования в контроллере. Это хорошая вещь для сравнения вещей и т. Д. Даже до того, как данные действительно будут сохранены.