Валидация это обычно что? Простыня) Поэтому свой Form Request. Написать php artisan make:request и потом импортировать в ide это буквально секунды времени. Зато в этом классе ты можешь кучу всего делать. Например prepareForValidation, сообщения, логику со своими правилами и все это будет в одном месте. Запихивать валидацию в middleware или в свои классы в Ларавел - это извращение.
Сделать так как быстрее. Понадобится переиспользовать вынесешь в отдельный. Все остальное - пустое и трата времени. Имхо Middleware вообще не то место.
Ну тут по ситуации. Если просто какой-то один абстрактный урл с небольшим количеством входных данных, то прямо в контроллере вполне ок. В Middleware можно пихнуть, если например у тебя несколько роутов с одинаковым набором параметров и валидацией для них.
В реквесте валидация на то, что клиент заполнил даннные. Слою http не нужно знать о базе данных, и логике приложения. Только проверка на корректность пользовательского ввода.
А вот валидация основная находится в слое приложения, который знает, в каком состоянии должны находится данные.
NubasLol, ты только что описал два процесса валидации, разделив на основную и не основную. Если тебе нужно изменить данные перед валидацией для этого есть prepareForValidation. Если нужно изменить данные перед записью в бд - меняй. Пользователь и валидация тут не причем. Валидация проверяет пользовательский ввод, который тебе нужен для дальнейшей логики. А для подстраховок и закрепления функционала есть тесты.
jazzus, Вот именно, пользовательский ввод. А например, есть модель заказа со статусами. И по апи можно менять статус у заказа. Где будет проверка на валидность статуса?
jazzus, а потом появится еще одно место где ты будешь создавать заказ, например через консоль или через админку. В итоге ты либо будешь писать валидацию для всех этих мест, либо у тебя ее вообще не будет.
NubasLol, еще через AdminController. Я понял) Для этого в Ларавел FormRequest class. Зачем тебе нужна валидация в консоли? Себе не доверяешь чтоли? или у теюбя юзеры консоль юзают?)
NubasLol, ну и пускай делают что хотят. База же локальная. Или ты на проде статусы через консоль меняешь? а если эти люди напишут delete all здесь чего делать? В любом случае это к валидации не имеет никакого отношения.
jazzus, зато имеет к SRP.
Но понимание этого приходит с опытом.
Я "двойную валидацию", которая на самом деле не двойная, поддерживаю двумя руками.
Валидация пользовательского ввоба - это одна задача, валидация модели - другая. Да, они пересекаются. Но это не повод вообще никак не валидировать модель
Роман Юрьевич Ипатьев, приведи пример проблемного кода. У тебя есть либо пользовательский ввод, либо свой (программиста). Какая может быть ситуация, что твоя модель получит не те данные, которые ты, как программист написал? И зачем это называть "валидацией". В статье, автор реально валидирует емейлы итд что бред полный, учитывая функционал Ларавел.
NubasLol, ну так крон точно знает какие нужны статусы - он же их не из воздуха берет. Ты же этот код написал. До разумного искусственного интеллекта мы еще не дожили.
NubasLol, ты описываешь бизнес логику. Не валидацию. И логика всегда знает статусы. Не всегда знает пользовательский ввод или ввод хитрит. И здесь нужна валидация. А в логике не нужна. Нужен нормальный код с тестами. И не в модели, а в сервис классе. И тем более валидация не нужна ни в какой консоли. В статье же автор делает настоящую валидацию своим классом + Ларавел. И ты скорее всего не знал, что форм реквест можно юзать в разных контроллерах, судя по твоим примерам и вопросам. А книжка наверняка старая, возможно когда-то без своих классов было сложно, сейчас у ЛАравел свои инструменты.
я же не говорю что их не нужно юзать, и сам их юзаю. Поверь мне, доку лары знаю не хуже тебя)
Ты писал тесты?
Я вот один раз попробовал, в итоге понял что фигня и бросил. Уходило больше времени чем на сам код, плюс постоянно нужно их менять вместе с кодом. А большинство ошибок ловить не помогали, ибо были такие кейсы, которые заранее и не подумаешь в тесте описать
NubasLol, если ты юзаешь форм реквесты откуда у тебя вопросы про проблему использования в разных контроллерах, которую ты с начала обозначил? и зачем нужна валидация этими dto-сервисами из книги? Ты с товарищем не привел ни одного примера где это может понадобиться. Приведи пример проблемы кодом, а не на словах. Примеры в статье бред и ересь, в Ларавел гораздо проще все делается.
NubasLol, я пишу вначале тесты, а потом разрабатываю. С тех пор, как использую такой подход у меня вообще нет ошибок на проде. Но я тесты не из-за ошибок пишу. Чтобы с консолью не возиться))
Вообще я предпочитаю дублирование такой логики, нежели писать что-то универсально, но сложное, а потом еще появляются всякие if когда в части кода меняются условия
jazzus, на самом деле вы оба правы.
просто валидаций может быть больше чем одна.
Для бизнес-логики тоже приходится валидировать.
Если рассуждать в терминах "Какая может быть ситуация", то тогда и строгая типизация в пхп тоже не нужна. "Ну откуда там другие типы возьмутся, если ты сам все данные заполнял?"
Роман Юрьевич Ипатьев, да я так и понял, что разговор ниочем) в статье не какая-то " валидация бизнес логики", а вполне нормальная. и в Ларавел делается по другому.
