Где входная проверка относится к приложению MVC?

Ответ 1

Я не думаю, что существует официальная передовая практика, ограничивающая проверку какой-либо одной части шаблона MVC. Например, ваш взгляд может (и должен) выполнить некоторую предварительную проверку с помощью Javascript. Контроллер должен также предлагать те же типы проверки, что и валидация, связанная с бизнес-логикой. Модель также может предлагать формы проверки, т.е. Сеттеры, не допускающие нулевые значения.

Там интересное обсуждение этого на joelonsoftware.

Ответ 2

Я думал об этом в течение долгого времени и после попытки проверки правильности как в контроллерах, так и в моделях.... наконец, я пришел к выводу, что для многих моих приложений... проверка правильности принадлежит модели, а не в контроллере. Зачем? Поскольку в будущем такая же модель может использоваться другими вызовами контроллера или API-интерфейсами... и тогда мне придется повторять процесс проверки снова и снова. Это нарушит DRY и приведет к многочисленным ошибкам. Плюс философски его модель, которая взаимодействует с базой данных (или другим постоянным хранилищем) и, таким образом, является своего рода "последним призывом к алкоголю", чтобы сделать это в любом случае.

Итак, я делаю мой перевод get/post в контроллере, а затем отправляю необработанные данные в модель для проверки и обработки. Конечно, я часто занимаюсь веб-приложениями php/mysql, и если вы делаете другие вещи, результаты могут отличаться. Надеюсь, это поможет кому-то.

Ответ 3

Валидация должна быть в модели

Только модель знает "детали" бизнеса. только модель знает, какие данные приемлемы, а какие нет. контроллер просто знает, как "использовать" модель.

например: скажем, нам нужна функциональность регистрации новых пользователей в нашей системе.

Модель:

 public function registerUser(User $user){
    //pseudo code
       //primitive validation
       if(!isInt($user->age)){
           //log the invalid input error
           return "age"; 
       }
       if(!isString($user->name)){
           //log the invalid input error
           return "name";
       }
       //business logic validation

        //our buisnees only accept grown peoples
        if($user->age < 18){
            //log the error
            return "age";
        }
        //our buisness accepts only users with good physique
        if($user->weight > 100){
            //log the error
            return "weight";
        }
        //ervery thing is ok ? then insert the user
        //data base query (insert into user (,,,) valeues (?,?,?,?))
        return true;
}

Теперь задание контроллера /s заключается в "использовании" функции модели registerUser() без знания того, как модель собирается выполнить валидацию или даже то, что считается "действительным" или нет!

Контроллер:

$user = new User();
$user->age = isset($_POST['age']) ?  $_POST['age'] : null;
$user->name = isset($_POST['name']) ?  $_POST['name'] : null;
$user->age = isset($_POST['weight']) ?  $_POST['weight'] : null;
$result = $theModel->registerUser($user);// <- the controller uses the model
if($result === true){
//build the view(page/template) with success message and die
}
$msg = "";
//use the return value from the function or you can check the error logs
switch ($result){
    case"age" :
        $msg = "Sorry, you must be over 18";
        break;
    case "name":
        $msg = "name field is not correct";
        break;
    case "weight":
        $msg = "Sorry, you must have a good physique";
        break;
}
//build the view(page/template) with error messages and die

Пользователь класса

class User { 
    public $age;
    public $name;
    public $weight;
}

имеющий такую ​​архитектуру, полностью "освободит" контроллеры от деталей бизнес-логики, что хорошо -

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

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

Ответ 4

Его бизнес-логика, поэтому нет, она не принадлежит модели.

Ответ 5

Внутри контроллера у вас есть свойство ModelState, к которому вы можете добавить ошибки проверки.

Смотрите этот пример в MSDN.

Ответ 6

Предполагая, что ваше приложение структурировано следующим образом:

• Model-View-Controller
• Сервис
• Постоянство
• Model

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

Ответ 7

Business Logic  -> Controller
Data Validation -> Model