DTO в laravel для requests а также обзор библиотеки от Spatie

Сегодня мы затронем тему DTO в Laravel - data transfer object. Рассмотрим, как работать с данными в структурированном виде. Научимся использовать объекты передачи данных (DTO).
#dto#laravel#cutcode
---------------------------------------------------------------------------------
❗️❗️❗️Присоединяйся к нашему комьюнити в телеграм - там и советом помогут и много интересного - t.me/laravel_chat
🤖🤖🤖Мой помощник Тэйлор готов выдать тебе подарок. Забирать тут - cutcode.ru/chat-bot
---------------------------------------------------------------------------------
⏰ Таймкоды:
00:00 Введение
00:31 Описание проблемы
01:52 Реализация DTO
03:36 Обзор библиотеки от Spatie
06:57 Подведение итогов
Всех поклонников Laravel я приветствую на канале Cutcode! Сегодня мы затронем тему DTO в ларавел - data transfer object. Быстро пройдемся по этой теме а также рассмотрим специальный пакет от spatie по организации слоя DTO в Laravel проекте. Обсудим с вами зачем это нужно, как с этим работать и мое личное мнение об этом паттерне.
Итак давайте начнём с проблемы - мы работаем с request в laravel. У нас есть валидация, есть метод validated который возвращает нам массив и мы находясь здесь ничего не знаем, что у нас в этом массиве, для нас он черный ящик. IDE нам также ничего не подскажет об этом массиве. Мы не знаем какие элементы в этом массиве в данном случае находится. Если мы работаем с FormRequest и провалимся в класс, там и хотя бы в методе rules можем увидеть какие именно параметры будет возвращать метод validated. Но если в целом мы работаем с request и возвращаем все параметры, то мы вообще понятия не имеем что там находится. Ну и здесь в целом тоже пока мы не уходим в класс, мы ничего о нем не знаем. Ошибиться в таком подходе гораздо проще. Да как минимум случайно ошибиться в написании ключа. Исправить сие недоразумение можно добавив дополнительный слой представления DTO и это всего лишь дополнительный класс, который примет все параметры из вашего массива с запросам и трансформирует объект перед определенными свойствами и типами и далее с ним работа будет выполнена удобно и IDE нам всегда подскажет что именно содержится в этом объекте. Давайте взглянем на такой объект и применим его в нашем примере.
Итак давайте взглянем на такой класс. Я его уже создал, располагается он у меня в директории DTO и здесь класс PostForm, который как раз ответственен за PostFormRequest. Давайте на него посмотрим как видите это простой класс ничего особенного в нем нет, за единственным исключением - присутствует статический метод FormRequest, который принимает объект Request и в последующем создает экземпляр класса FormRequest на основе параметров которые у нас как раз находятся в методе Rules, который у нас возвращаются от метода validated. Далее в контроллере нам необходимо немножко изменить наш код - убрать RequestValidated - здесь обратиться к PostForm обратиться к методу FormRequest параметрам отдать объект FormRequest и в конечном итоге работать с датой как с экземпляром класса PostForm. И здесь уже IDE нам спокойно подсказывает, какие свойства есть какие методы, плюс мы в самом классе можем указать какие типы у свойств. И работать в таком ключе будет гораздо удобнее.
---------------------------------------------------------------------------------
📹 делитесь этим видео с друзьями:
• DTO в laravel для requ...
🔔 подпишитесь на KZbin-канал: kzbin.info?s...
📼 Курс по Laravel с нуля:
• Курс по Laravel 8 обуч...
DTO в laravel для requests а также обзор библиотеки от Spatie
---------------------------------------------------------------------------------
🔗 наш сайт: cutcode.ru/
📷 наш instagram: / cutcoderu
📱 Наш telegram-канал: t.me/laravel_cutcode

[@RuslanMavlyanov]

КОмментарий для поддержки такого красавчика, который пилит годные четкие ясные видео. Респект ❤

[@CutCodeRu]

@@RuslanMavlyanov благодарю

[@quliyevrustam]

Спасибо! Не пользуюсь Laravel, но хотя бы стало понятно что такое DTO

[@Sadr-se6qv]

Отличное объяснение! Спасибо большое!

[@artorios5192]

Спасибо, не знал про это раньше. В принципе, тоже считаю, это дополнительным наслоением. Вряд ли буду использовать)

[@CutCodeRu]

Но знать надо)

[@PanoOdUa]

Если данные из реквеста использовать прямо в методе контролера, то скорее да, дто не нужен. Но если данные нужно отправить в обработку дальше в сервисный слой, или еще глубже, отправить в очердь, то согласитесь, пихать туда реквест уже смешно :)

[@artorios5192]

@@PanoOdUa согласен! Сам себя иногда останавливаю от этого 🤣

[@nickname20151]

Мне кажется самописный вариант с классом для DTO и аннотациями лучше, чем использовать пакет.

[@CutCodeRu]

👌

[@gunho1324]

Здравствуйте в этом канале очень полезные уроки. Можете подсказать еще о phpDoc в Laravel. Как правильно написать аннотацию к моделу, контроллеру и так дале. Спасибо болшое!

[@CutCodeRu]

Гляньте в сторону github.com/barryvdh/laravel-ide-helper Сгенерируйте аннотации и посмотрите как это выглядит, а так думаю сниму отдельный ролик на эту тему

[@SergeyNeskhodovskiy]

Как и любой инструмент, о DTO нужно просто знать где оно к месту, а где - нет. А так получается "молотком неудобно доски пилить, поэтому я считаю его бесполезным инструментом и в работе не использую". Один из кейсов, например, где DTO может иметь кроме базовых, также вычисляемые или форматируемые на лету свойства. Но при этом не является сохраняемой в базе моделью. И тогда мы инкапсулируем эту функциональность в DTO и мы красавчики. А ещё например для передачи данных при взаимодействиях между разными модулями и пакетами большого приложения, между разными сервисами микросервисного приложения, для отправки данных в очередь обработки и тд.

[@CutCodeRu]

Dto используется повседневно во многих кейсах, я же сделал упор на validated в form request как случай когда можно использовать но сам в этом случае не использую, короче запутал и плохо преподнес, пересниму более качественно, спасибо за комментарий

[@rosamarsky]

Лучший ответ под этим видео:)

[@SergeyNeskhodovskiy]

Я прошу прощения если мой комментарий прозвучал слишком резко ) Не хотел обидеть, хотел просто реально привести примеры где паттерн DTO более к месту.

[@rosamarsky]

Достаточно просто добавить гетеры либо @property аннотации для FormRequest класса. Он и так является DTO, пусть и нарушает SRP, но в Laravel нарушать SRP - это уже давно вариант нормы:)

[@CutCodeRu]

Речь просто не о в целом о form request а о методе validated который возвращает массив

[@rosamarsky]

@@CutCodeRu The incoming form request is validated before the controller method is called, meaning you do not need to clutter your controller with any validation logic. Т.e. $request->validated(), то же что и request->all() и делать из параметров "формы" еще один класс с теми же параметрами, как по мне, не имеет смысла, когда можно просто добавить гетеры:)

[@CutCodeRu]

@@rosamarsky ты говоришь прл validate() а я говорю прл validated() который получает все поля которые участвовали в валидации уже после успешной валидации)) понял?

[@CutCodeRu]

Вообщем можно по разному, здесь озвучен один и вариантов

[@user-no6ke4sq4m]

Я бы сказал, что ДТО все больше начинают использовать на практике, особенно в REST API, где нужно не только из запроса создать ДТО, но и вернуть в ответе как JSON объект. Скорее всего в Ларавеле тоже можно как у Симфони зарезолвить ДТО как аргумент конролера и тогда в контроллер будет прихордить уже готовые данные, в том числе провалидированые

[@CutCodeRu]

готовых инструментов в ларавел для этого нет но самостоятельно обвернуть ничего не мешает и сложности в этом нет

[@snowy8465]

нету в Ларе этого((( Но было бы очень круто, надеюсь скопипастят

[@SergeyNeskhodovskiy]

Как это нету, если аргументы контроллера автоматически резолвятся в Ларавеле из IoC контейнера с незапамятных времен. И тайп-хинтнуть можно не только реквест а и вообще любой класс. В том числе и DTO. Ну а если мы тайп-хинтнули наследник FormRequest, то он также будет приходить в контроллер уже провалидированный - разве не это имелось в виду? И что мешает, как тут уже в другом комментарии ответили, класс реквеста превратить в DTO? Для этого достаточно даже не писать в него никакой логики а просто снабдить правильными аннотациями свойств. И в IDE появляются подсказки )

[@snowy8465]

Если нужна подсветка ide, просто приватные свойства пишешь в классе реквеста, и в методе passedValidation присваиваешь. Иногда так делаю, если много потом возни с данными) помню Орвелл говорил что классы реквестов все недооценивают, и не думают о них как о обычных классах. Ни методов туда не пишут ни свойств. Но чаще всего нафиг надо в реквестах это творить))

[@CutCodeRu]

Не помню сказал или нет в ролике но я на практике dto использую крайне редко, ну а то что можно дописать свойства это само собой, можно выбрать и такой путь) меня как правило и массив не особо пугает)

[@Kyrare03]

Не совсем понял, но вроде первый пример, без пакета, остался без валидации. Там валидацию делаем также, как в примере с пакетом?

[@CutCodeRu]

добрый день! приглашаю в наш чат t.me/laravel_chat, там на вопросы отвечаем быстрее

[@eldaeron]

А субтитры подсказывают что нужно использовать Детей, а не ДТО )

[@PanoOdUa]

А если такой DTO указать в параметрах метода update вместо PostFormRequest, а в самом DTO в конструкторе указать этот самый форм реквест, то контейнер сам все сделает и не нужно писать лишнюю строку в методе. ;)

[@CutCodeRu]

Не увидел ваш комментарий сразу! Просто гениальная реализация!

[@user-qd6hj2fn4w]

какой хитрец)) КРАСАВА!!!

[@FuriousDin]

Выпускать видео о DTO и прям в видео говорить что я его не использую это как минимум сразу толкает человека на мысль что это муссорный паттерн. А теперь к паттерну. Основное преимущество в этом паттерне это то что я получаю слепок данных готовый работе с которым я буду 100% уверен что дальше не получу где-то null. Это проявляться когда вы не создаете FormRequest а создаете композицию из данных из раных классов или же источников (ввод, база и тд). И так вы получили набор данных и вам нужно их прокинуть в метод. Раньше это делалось через массив или отдельными аргументами метода. 1) при прокидывании массива это не гарантирует что они там есть, + отсутствие автокомплита. 2) когда мы передаем слепок переменных через аргументы это лочит расширение данного метода в будущем, а так же мы ломает наши юнит тесты и их нужно все переписывать. Прелесть как раз так таки в том что мы описывает набор свойств которые должны в нём быть и гарантированно получаем их в дальнейших экземплярах в которые удобно загружать и расширять. Когда же вы используете массив и прокидываете его дальше по коду и нет такой вероятности что какой нибудь джун случайно не подрежит какой-то ключ или не переопределит его. Всё выше перечисленное относится только к большим проектам там где много разработав, там где естественно важна скорость массивы ваше все.

[@CutCodeRu]

Четко сказано

[@CutCodeRu]

Но не всегда в больших проектах, встречаются сплошь и рядом, к примеру при работе с api и реализации моделей на основе json данных и особенно актуально при разработке мобильных приложений на других языках программирования

[@CutCodeRu]

Я в ролике имел ввиду что не использую для form request

[@CutCodeRu]

Но в целом ролик вышел не понятный и с множеством вопросом, скорее всего сделаю новую версию)

[@FuriousDin]

​@@CutCodeRu так же стоит добавить что с новой версией PHP это уже будет в нём самом. Всё равно, спасибо за труд.

[@NguyenMinh-gl7qz]

I think the DTO properties is public, then you don't need set method anyway :D (Or you should set properties to private so that make sense)

[@alexstav3457]

А насчет ДТО для данных из БД.. слышал что и тут их используют. Но как, какой смысл, в чем удобство? у нас же есть и так класс Коллекшен, или выбирать то или другое надо. или из БД в ДТО, потом в колекшен, потом в виде уже выводить... над больше примеров... запутано

[@CutCodeRu]

Для моделей еще делают, я вроде сказал об этом, так как в моделях тоже не ясно какие поля есть как и в массивах

[@snowy8465]

для моделей из бд там паттерн такой есть. Суть что имплентация Orm, в Ларе Active record. это удобно, быстро писать и... ужасно))) В больших компаниях с большими продуктами пишущиеся годами, и с большой командой разработчиков это не прокатывает. Потому что требования меняются, поля в базе меняются каждый день, одни утсаревают другие нет, другие только для совместимости, и тебе нужен этот уровень абстракции чтобы навести хоть какой то порядок. Для этого и делается пародия на нормальную ORM, Data mapper. Когда класс с данными из БД не связан с логикой твоего приложения. Изменилось поле, изменил значение в одном классе и всеее. Кайф) поле было инт стало стринг (для примера), не бегаешь по тысячам строк кода а в одном классе добавляешь каст и всеее)) Data mapper по дефолту в Симфони, и это одна из причин почему для корпоративной разработки рекомендуется Симфони а не Лара. Вообще орм в ларе такая себе, когда значения в базе становятся 7-8 значными, нужно постоянно следить что там Лара накидала в SQL((( боль

[@user-mf5ub9fl8s]

@@CutCodeRu это больные симфонисты, у них ломка без сука сущностей

[@silentage6310]

указанные примеры слишком простые чтобы раскрыть преимущества DTO. если у вас сложная логика бизнес модели - то очень даже пригодится, т.к. передавать request везде очень стремно, функции которые принимают реквесты не переиспользуемые. долго расписывать, надеюсь поняли. альтернатива им только массивами все передавать...

[@CutCodeRu]

Если будет интерес к теме, сделаем более подробный ролик

[@silentage6310]

@@CutCodeRu со всем уважением, но откуда он возьмется елси тема подана как "DTO это обертка над реквестом и нафиг не нужна"?

[@CutCodeRu]

@@silentage6310 скорее всего переделаю с другим примером и подачей

[@darakanoit]

С laravel idea подскажет, что в реквесте на основе rules

[@CutCodeRu]

если хотите быстро получать помощь - пишите сюда - t.me/laravel_chat

[@user-fg9ps9tk6i]

Жаль, что не видно реализации методов класса DTO, которые Вы затем удалили :) Зато поля класса аж на 6 строк :)

[@lexxkrt]

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

[@bubblesort6368]

А зачем создавать какой-то специфический DTO, если можно просто геттеры добавить в класс request, вместо дерганья даты напрямую? Не будет лишней статической фабрики в теле контроллера.

[@CutCodeRu]

Ну тут суть в примере метод validated который возвращает массив и его сконвертировать в обьект и быть уверенным в типах и полях, ситуативно... ролик получился неоднозначным, буду переснимать с другим примером и упрощать подачу

[@snowy8465]

Пакет от Spatie выглядит перебором, чаще всего кроме toArray ничего и не надо, зачем куча этих методов. И далее если надо то в collect обернул и то же самое.. Да и зачем пакет когда в ide две кнопки нажал и вот тебе дто. Не понятно как то в чем преимущество, в php8.1 readonly уже будет для ДТО, ещё меньше причин для пакета. Мб я что то не улавливаю?

[@CutCodeRu]

Согласен про перебор)

[@user-gk3xo5lf2q]

Какой то интерфейс, абстрактный метод...., но как по мне, легче провалиться в класс,или писать php doc...

[@CutCodeRu]

речь ведь не о классе а о массиве) с классами то все понятно в большинстве случаев (за исключением того же примера в ролике с моделями у которых свойства получены магическими методами и они не явно указаны)

[@jonik_doit4463]

в php8 парамсы из реквеста можно сразу в конструктор дто через ... синтаксис забросить будет что-то типа такого: $someDto = new SomeDto(...$request->validated());

[@prakctoleb1974]

Как раз ознакамливался с этим пакетом от спати

[@user-mf5ub9fl8s]

А зачем городить аля из секты симфони мусор если в ларавель реквесты и апи ресурсы и так есть? Это для больных симфони которых вдруг заставили в ларавель писать