Где лучше проверять входные данные, в контроллере или в модели?
Проверять данные в контроллере, сразу после отправки их пользователем, или в моделе, перед записью в базу?
Как на ваш взгляд правильно? И по возможности посоветуйте либу для валидации входящих данных.
Данные надо проверять там, где они есть (гуглить "GRASP информационный эксперт").
В вашем случае мы говорим о "входящих данных". В контексте вопроса стало быть мы говорим о контроллере. Для модели данные тоже будут "входящими" но это уже будут данные в формате модели (например вместо строки готовый DateTime объект и т.д.)
Модель же не должна входить в "невалидное состояние" за счет бизнес правил и т.д (банально не должно быть возможности вызвать какой-то метод и сломать целостность состояния модели). А стало быть валидировать ее нет смысла.
Тоесть в данном случае контроллеры будут достаточно толстыми. Я много где читал что в контроллере может быть всего несколько строк кода. Может посоветуете нормальный пример mvc приложения? Или адекватную информацию про это. Я как новичек хочу идти по правильному пути)
Андрей Безруков: контроллеры не будут толстыми. DRY и все такое. Можно мэпить запрос на отдельные объекты и реализовывать валидацию на этом уровне (в laravel вон есть FormRequest-ы), можно на уровне мидлвэров, можно еще как.
Суть тонких контроллеров в том, что у вас должен быть один вызов метода одного сервиса на экшен контроллера. Или два (если у нас разделено чтение и запись на два разных сервиса)... или в цикле если пакетная обработка. Но суть в том, что бы делигировать выполнение другой штуке, а сам контроллер может только конвертить данные из формата HTTP в формат модели.
Я бы рекомендовал вам просто не загоняться по MVC, максимум почитать про separation of concerns и smartui (как антипаттерн).
Не понял ораторов выше. Модель должна только работать с базой, всё! Больше ничего. Контроллер должен обрабатывать логику, вьюхи отображать всё это. Поэтому фильтровать нужно только в контроллере.
модель это не "только база и все", это огромный слой который содержит как данные так и поведение по работе с этими данными. Неужели надо опять писать статью в духе "что такое MVC или зачем нам separation of presentation".
Илья Трусов: когда люди начинают говорить о базе данных в контексте MVC - все сразу становится сложнее. И тут либо человек не понимает что такое MVC либо под этими тремя буквами подразумевает какой-нибудь Model2.
Сергей Протько: Что вы имеете в виду? В запросе /?temperature=-5 - значение temperature валидное или нет? Как ответить на этот вопрос без привлечения модели?
Aracon: в контексте запроса - оно может быть валидным. Более простой пример - проверка email на уникальность. На уровне валидации в контроллере - мы проверяем только является ли строка email-ом и заполнено ли оно. А проверять уникальность будет уже модель при попытке сохранения или же отдельно в репозитории, когда мы сохраняем объект. То есть по хорошему валидация должна происходить в контроллере, а если данные пошли дальше - дальше их должны хэндлить бизнес правила и органичения.
