Где в Laravel лучше делать валидацию входящих данных — в контроллере или сделать кастомный Request для контроллера, или Middleware?

Question

[Роми]

сабж :)

Какой подход будет самый лучший с точки зрения ООП и всего такого прочего?

Или вынести в отдельный сервис-класс?

Или что-то еще?

Как правильно?

Answer 1

[jazzus]

Валидация это обычно что? Простыня) Поэтому свой Form Request. Написать php artisan make:request и потом импортировать в ide это буквально секунды времени. Зато в этом классе ты можешь кучу всего делать. Например prepareForValidation, сообщения, логику со своими правилами и все это будет в одном месте. Запихивать валидацию в middleware или в свои классы в Ларавел - это извращение.

Answer 2

[pLavrenov]

Сделать так как быстрее. Понадобится переиспользовать вынесешь в отдельный. Все остальное - пустое и трата времени. Имхо Middleware вообще не то место.

Answer 3

[Илья]

Ну тут по ситуации. Если просто какой-то один абстрактный урл с небольшим количеством входных данных, то прямо в контроллере вполне ок. В Middleware можно пихнуть, если например у тебя несколько роутов с одинаковым набором параметров и валидацией для них.

Answer 4

[Ипатьев]

Вообще-то в Ларе УЖЕ есть этот самый отдельный сервис - Illuminate\Http\Request, который и предназначен для валидации входящих данных.

Comments

[Егор Соколов]

"А у Вас брат в Москве есть?" Напоминаете другого пользователя, но он что-то давненько здесь не появлялся.

[Ипатьев]

И правда. Отредактировал ответ, чтобы не напоминать

Answer 5

[NubasLol]

Неплохая заметка о валидации

https://github.com/adelf/acwa_book_ru/blob/master/...

Comments

[jazzus]

Двойная валидация это мощно.

[NubasLol]

jazzus, да нет, там валидация не двойная.

В реквесте валидация на то, что клиент заполнил даннные. Слою http не нужно знать о базе данных, и логике приложения. Только проверка на корректность пользовательского ввода.

А вот валидация основная находится в слое приложения, который знает, в каком состоянии должны находится данные.

[jazzus]

NubasLol, ты только что описал два процесса валидации, разделив на основную и не основную. Если тебе нужно изменить данные перед валидацией для этого есть prepareForValidation. Если нужно изменить данные перед записью в бд - меняй. Пользователь и валидация тут не причем. Валидация проверяет пользовательский ввод, который тебе нужен для дальнейшей логики. А для подстраховок и закрепления функционала есть тесты.

[NubasLol]

jazzus, Вот именно, пользовательский ввод. А например, есть модель заказа со статусами. И по апи можно менять статус у заказа. Где будет проверка на валидность статуса?

[jazzus]

NubasLol, в OrderRequest правило exists. А в чем проблема не догоняю?)

[NubasLol]

jazzus, а потом появится еще одно место где ты будешь создавать заказ, например через консоль или через админку. В итоге ты либо будешь писать валидацию для всех этих мест, либо у тебя ее вообще не будет.

[jazzus]

NubasLol, StoreOrderRequest это класс https://laravel.com/docs/8.x/validation#form-reque.... Его можно использовать в неограниченном числе мест.

[NubasLol]

jazzus, и в консоли?)

[jazzus]

NubasLol, зачем тебе в консоли валидация?

[NubasLol]

jazzus, потому что статус может меняться не только через один апи контроллер

[jazzus]

NubasLol, еще через AdminController. Я понял) Для этого в Ларавел FormRequest class. Зачем тебе нужна валидация в консоли? Себе не доверяешь чтоли? или у теюбя юзеры консоль юзают?)

[NubasLol]

jazzus, доверять нельзя никому) тем более, могут работать несколько человек над одним проектом.

Хорошо когда о своей консистентности заботится сам объект, а не какой-то другой, который с ним вообще никак не связан.

[jazzus]

NubasLol, ну и пускай делают что хотят. База же локальная. Или ты на проде статусы через консоль меняешь? а если эти люди напишут delete all здесь чего делать? В любом случае это к валидации не имеет никакого отношения.

[Ипатьев]

jazzus, зато имеет к SRP.
Но понимание этого приходит с опытом.
Я "двойную валидацию", которая на самом деле не двойная, поддерживаю двумя руками.
Валидация пользовательского ввоба - это одна задача, валидация модели - другая. Да, они пересекаются. Но это не повод вообще никак не валидировать модель

[NubasLol]

jazzus, логика смены заказов вещь сложная, может быть по крону, может быть через 1с, еще через какой порт, и везде разная валидация.

Прочитай внимательно. Вообще всю книгу советую

[jazzus]

Роман Юрьевич Ипатьев, приведи пример проблемного кода. У тебя есть либо пользовательский ввод, либо свой (программиста). Какая может быть ситуация, что твоя модель получит не те данные, которые ты, как программист написал? И зачем это называть "валидацией". В статье, автор реально валидирует емейлы итд что бред полный, учитывая функционал Ларавел.

[jazzus]

NubasLol, ну так крон точно знает какие нужны статусы - он же их не из воздуха берет. Ты же этот код написал. До разумного искусственного интеллекта мы еще не дожили.

[jazzus]

NubasLol, скорее всего это писалось в древние времена. Когда не было форм реквестов и тд. Для современного Ларавел это 100% говнокод

[NubasLol]

jazzus, какой самый крупный проект ты делал?

[jazzus]

NubasLol, давай без понтов) пиши суть

[NubasLol]

jazzus, дело не в понтах, просто когда в 10+ местах кода меняется тот же статус, обязательно нужно его валидировать в самой сущности

Особенно когда логика статусов сложная, не может быть заказ готов, пока со склада не отгружен товар (условно)

[jazzus]

NubasLol, ты описываешь бизнес логику. Не валидацию. И логика всегда знает статусы. Не всегда знает пользовательский ввод или ввод хитрит. И здесь нужна валидация. А в логике не нужна. Нужен нормальный код с тестами. И не в модели, а в сервис классе. И тем более валидация не нужна ни в какой консоли. В статье же автор делает настоящую валидацию своим классом + Ларавел. И ты скорее всего не знал, что форм реквест можно юзать в разных контроллерах, судя по твоим примерам и вопросам. А книжка наверняка старая, возможно когда-то без своих классов было сложно, сейчас у ЛАравел свои инструменты.

[NubasLol]

jazzus,

форм реквест можно юзать

я же не говорю что их не нужно юзать, и сам их юзаю. Поверь мне, доку лары знаю не хуже тебя)

Ты писал тесты?

Я вот один раз попробовал, в итоге понял что фигня и бросил. Уходило больше времени чем на сам код, плюс постоянно нужно их менять вместе с кодом. А большинство ошибок ловить не помогали, ибо были такие кейсы, которые заранее и не подумаешь в тесте описать

[NubasLol]

jazzus, https://github.com/adelf/freelance-example

Посмотри полный пример из книги, там есть форм реквесты

[jazzus]

NubasLol, если ты юзаешь форм реквесты откуда у тебя вопросы про проблему использования в разных контроллерах, которую ты с начала обозначил? и зачем нужна валидация этими dto-сервисами из книги? Ты с товарищем не привел ни одного примера где это может понадобиться. Приведи пример проблемы кодом, а не на словах. Примеры в статье бред и ересь, в Ларавел гораздо проще все делается.

[jazzus]

NubasLol, я пишу вначале тесты, а потом разрабатываю. С тех пор, как использую такой подход у меня вообще нет ошибок на проде. Но я тесты не из-за ошибок пишу. Чтобы с консолью не возиться))

[NubasLol]

jazzus, а ты юзаешь один форм реквест для разных контроллеров?

[jazzus]

NubasLol, если запросы одинаковые то да

[NubasLol]

jazzus, почему тогда это разные котроллеры))

Вообще я предпочитаю дублирование такой логики, нежели писать что-то универсально, но сложное, а потом еще появляются всякие if когда в части кода меняются условия

[jazzus]

NubasLol,
PostController
store
Admin/PostController
store
= StorePostRequest

[jazzus]

NubasLol, потому что как минимум права разные

[NubasLol]

jazzus, если потом в админ Admin/PostController добавится что-то, как ты будешь делать? например возможность изменить дату для post

[jazzus]

NubasLol, выношу общее в трейт и в разные реквесты. Разные запросы - разные реквесты

[jazzus]

NubasLol, на гитхабе в примере действительно юзаются форм реквесты с каким-то говнокодом, но в статье я их не заметил.

[Ипатьев]

jazzus, на самом деле вы оба правы.
просто валидаций может быть больше чем одна.
Для бизнес-логики тоже приходится валидировать.

Если рассуждать в терминах "Какая может быть ситуация", то тогда и строгая типизация в пхп тоже не нужна. "Ну откуда там другие типы возьмутся, если ты сам все данные заполнял?"

[jazzus]

Роман Юрьевич Ипатьев, да я так и понял, что разговор ниочем) в статье не какая-то " валидация бизнес логики", а вполне нормальная. и в Ларавел делается по другому.