Где лучше проверять входные данные, в контроллере или в модели?

Question

[dev400]

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

Comments

[dev400]

Neoline: да пишу проект, хочется сделать правильно. Вдруг потом (через полгодика) придется переписывать уже не 5-10 файлов, а гораздо больше....

[Дмитрий]

Вообще не надо ничего проверять. Пусть пользователь сам всё проверяет. А то совсем обленились!

Answer 1

[Сергей Протько]

Данные надо проверять там, где они есть (гуглить "GRASP информационный эксперт").

В вашем случае мы говорим о "входящих данных". В контексте вопроса стало быть мы говорим о контроллере. Для модели данные тоже будут "входящими" но это уже будут данные в формате модели (например вместо строки готовый DateTime объект и т.д.)

Модель же не должна входить в "невалидное состояние" за счет бизнес правил и т.д (банально не должно быть возможности вызвать какой-то метод и сломать целостность состояния модели). А стало быть валидировать ее нет смысла.

Comments

[dev400]

Тоесть в данном случае контроллеры будут достаточно толстыми. Я много где читал что в контроллере может быть всего несколько строк кода. Может посоветуете нормальный пример mvc приложения? Или адекватную информацию про это. Я как новичек хочу идти по правильному пути)

[Сергей Протько]

Андрей Безруков: контроллеры не будут толстыми. DRY и все такое. Можно мэпить запрос на отдельные объекты и реализовывать валидацию на этом уровне (в laravel вон есть FormRequest-ы), можно на уровне мидлвэров, можно еще как.

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

Я бы рекомендовал вам просто не загоняться по MVC, максимум почитать про separation of concerns и smartui (как антипаттерн).

Answer 2

[Илья Трусов]

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

Comments

[Сергей Протько]

модель это не "только база и все", это огромный слой который содержит как данные так и поведение по работе с этими данными. Неужели надо опять писать статью в духе "что такое MVC или зачем нам separation of presentation".

[Илья Трусов]

Сергей Протько: Мне не надо объяснять, что такое MVC.

Да и сами Вы ниже в комментарии дали ответ, что фильтровать надо в контроллере.
Только расписали всё в терминологии.

[Сергей Протько]

Илья Трусов: когда люди начинают говорить о базе данных в контексте MVC - все сразу становится сложнее. И тут либо человек не понимает что такое MVC либо под этими тремя буквами подразумевает какой-нибудь Model2.

Answer 3

[Андрей]

с данными работает модель, и только модель...
по хорошему, валидировать их в setter'е в момент присвоения.

Comments

[Сергей Протько]

сеттеры - прямое нарушение инкапсуляции. Почему всем так нравятся анемичные модели... это ж антипаттерн.

Answer 4

[Marcuzy]

В модели, а логика простая: модель может использоваться во многих местах.

Answer 5

[Aracon]

Ещё такой момент: только модель знает, какие данные валидные, а какие нет. Само понятие валидных данных является частью модели.

Comments

[Сергей Протько]

есть такой момент - только контроллер знает какой http реквест содержит валидные данные а какой нет.

[Aracon]

Сергей Протько: Что вы имеете в виду? В запросе /?temperature=-5 - значение temperature валидное или нет? Как ответить на этот вопрос без привлечения модели?

[Сергей Протько]

Aracon: в контексте запроса - оно может быть валидным. Более простой пример - проверка email на уникальность. На уровне валидации в контроллере - мы проверяем только является ли строка email-ом и заполнено ли оно. А проверять уникальность будет уже модель при попытке сохранения или же отдельно в репозитории, когда мы сохраняем объект. То есть по хорошему валидация должна происходить в контроллере, а если данные пошли дальше - дальше их должны хэндлить бизнес правила и органичения.