Это видео недоступно.
Сожалеем об этом.
DTO в laravel для requests а также обзор библиотеки от Spatie
HTML-код
- Опубликовано: 14 авг 2024
- Сегодня мы затронем тему DTO в Laravel - data transfer object. Рассмотрим, как работать с данными в структурированном виде. Научимся использовать объекты передачи данных (DTO).
#dto#laravel#cutcode
---------------------------------------------------------------------------------
❗️❗️❗️Присоединяйся к нашему комьюнити в телеграм - там и советом помогут и много интересного - t.me/laravel_chat
🤖🤖🤖Мой помощник Тэйлор готов выдать тебе подарок. Забирать тут - cutcode.ru/cha...
---------------------------------------------------------------------------------
⏰ Таймкоды:
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...
🔔 подпишитесь на RUclips-канал: www.youtube.co...
📼 Курс по Laravel с нуля:
• Курс по Laravel 8 обуч...
DTO в laravel для requests а также обзор библиотеки от Spatie
---------------------------------------------------------------------------------
🔗 наш сайт: cutcode.ru/
📷 наш instagram: / cutcoderu
📱 Наш telegram-канал: t.me/laravel_c...
КОмментарий для поддержки такого красавчика, который пилит годные четкие ясные видео. Респект ❤
@@RuslanMavlyanov благодарю
Спасибо, не знал про это раньше. В принципе, тоже считаю, это дополнительным наслоением. Вряд ли буду использовать)
Но знать надо)
Если данные из реквеста использовать прямо в методе контролера, то скорее да, дто не нужен. Но если данные нужно отправить в обработку дальше в сервисный слой, или еще глубже, отправить в очердь, то согласитесь, пихать туда реквест уже смешно :)
@@PanoOdUa согласен! Сам себя иногда останавливаю от этого 🤣
Отличное объяснение! Спасибо большое!
Мне кажется самописный вариант с классом для DTO и аннотациями лучше, чем использовать пакет.
👌
Спасибо! Не пользуюсь Laravel, но хотя бы стало понятно что такое DTO
Здравствуйте в этом канале очень полезные уроки. Можете подсказать еще о phpDoc в Laravel. Как правильно написать аннотацию к моделу, контроллеру и так дале. Спасибо болшое!
Гляньте в сторону github.com/barryvdh/laravel-ide-helper
Сгенерируйте аннотации и посмотрите как это выглядит, а так думаю сниму отдельный ролик на эту тему
Как и любой инструмент, о DTO нужно просто знать где оно к месту, а где - нет. А так получается "молотком неудобно доски пилить, поэтому я считаю его бесполезным инструментом и в работе не использую". Один из кейсов, например, где DTO может иметь кроме базовых, также вычисляемые или форматируемые на лету свойства. Но при этом не является сохраняемой в базе моделью. И тогда мы инкапсулируем эту функциональность в DTO и мы красавчики. А ещё например для передачи данных при взаимодействиях между разными модулями и пакетами большого приложения, между разными сервисами микросервисного приложения, для отправки данных в очередь обработки и тд.
Dto используется повседневно во многих кейсах, я же сделал упор на validated в form request как случай когда можно использовать но сам в этом случае не использую, короче запутал и плохо преподнес, пересниму более качественно, спасибо за комментарий
Лучший ответ под этим видео:)
Я прошу прощения если мой комментарий прозвучал слишком резко ) Не хотел обидеть, хотел просто реально привести примеры где паттерн DTO более к месту.
Достаточно просто добавить гетеры либо @property аннотации для FormRequest класса. Он и так является DTO, пусть и нарушает SRP, но в Laravel нарушать SRP - это уже давно вариант нормы:)
Речь просто не о в целом о form request а о методе validated который возвращает массив
@@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() и делать из параметров "формы" еще один класс с теми же параметрами, как по мне, не имеет смысла, когда можно просто добавить гетеры:)
@@rosamarsky ты говоришь прл validate() а я говорю прл validated() который получает все поля которые участвовали в валидации уже после успешной валидации)) понял?
Вообщем можно по разному, здесь озвучен один и вариантов
Не совсем понял, но вроде первый пример, без пакета, остался без валидации. Там валидацию делаем также, как в примере с пакетом?
добрый день! приглашаю в наш чат t.me/laravel_chat, там на вопросы отвечаем быстрее
Я бы сказал, что ДТО все больше начинают использовать на практике, особенно в REST API, где нужно не только из запроса создать ДТО, но и вернуть в ответе как JSON объект. Скорее всего в Ларавеле тоже можно как у Симфони зарезолвить ДТО как аргумент конролера и тогда в контроллер будет прихордить уже готовые данные, в том числе провалидированые
готовых инструментов в ларавел для этого нет но самостоятельно обвернуть ничего не мешает и сложности в этом нет
нету в Ларе этого((( Но было бы очень круто, надеюсь скопипастят
Как это нету, если аргументы контроллера автоматически резолвятся в Ларавеле из IoC контейнера с незапамятных времен. И тайп-хинтнуть можно не только реквест а и вообще любой класс. В том числе и DTO. Ну а если мы тайп-хинтнули наследник FormRequest, то он также будет приходить в контроллер уже провалидированный - разве не это имелось в виду? И что мешает, как тут уже в другом комментарии ответили, класс реквеста превратить в DTO? Для этого достаточно даже не писать в него никакой логики а просто снабдить правильными аннотациями свойств. И в IDE появляются подсказки )
Если нужна подсветка ide, просто приватные свойства пишешь в классе реквеста, и в методе passedValidation присваиваешь. Иногда так делаю, если много потом возни с данными)
помню Орвелл говорил что классы реквестов все недооценивают, и не думают о них как о обычных классах. Ни методов туда не пишут ни свойств.
Но чаще всего нафиг надо в реквестах это творить))
Не помню сказал или нет в ролике но я на практике dto использую крайне редко, ну а то что можно дописать свойства это само собой, можно выбрать и такой путь) меня как правило и массив не особо пугает)
указанные примеры слишком простые чтобы раскрыть преимущества DTO.
если у вас сложная логика бизнес модели - то очень даже пригодится, т.к. передавать request везде очень стремно, функции которые принимают реквесты не переиспользуемые.
долго расписывать, надеюсь поняли. альтернатива им только массивами все передавать...
Если будет интерес к теме, сделаем более подробный ролик
@@CutCodeRu со всем уважением, но откуда он возьмется елси тема подана как "DTO это обертка над реквестом и нафиг не нужна"?
@@silentage6310 скорее всего переделаю с другим примером и подачей
Выпускать видео о DTO и прям в видео говорить что я его не использую это как минимум сразу толкает человека на мысль что это муссорный паттерн.
А теперь к паттерну. Основное преимущество в этом паттерне это то что я получаю слепок данных готовый работе с которым я буду 100% уверен что дальше не получу где-то null. Это проявляться когда вы не создаете FormRequest а создаете композицию из данных из раных классов или же источников (ввод, база и тд). И так вы получили набор данных и вам нужно их прокинуть в метод. Раньше это делалось через массив или отдельными аргументами метода.
1) при прокидывании массива это не гарантирует что они там есть, + отсутствие автокомплита.
2) когда мы передаем слепок переменных через аргументы это лочит расширение данного метода в будущем, а так же мы ломает наши юнит тесты и их нужно все переписывать.
Прелесть как раз так таки в том что мы описывает набор свойств которые должны в нём быть и гарантированно получаем их в дальнейших экземплярах в которые удобно загружать и расширять.
Когда же вы используете массив и прокидываете его дальше по коду и нет такой вероятности что какой нибудь джун случайно не подрежит какой-то ключ или не переопределит его.
Всё выше перечисленное относится только к большим проектам там где много разработав, там где естественно важна скорость массивы ваше все.
Четко сказано
Но не всегда в больших проектах, встречаются сплошь и рядом, к примеру при работе с api и реализации моделей на основе json данных и особенно актуально при разработке мобильных приложений на других языках программирования
Я в ролике имел ввиду что не использую для form request
Но в целом ролик вышел не понятный и с множеством вопросом, скорее всего сделаю новую версию)
@@CutCodeRu так же стоит добавить что с новой версией PHP это уже будет в нём самом.
Всё равно, спасибо за труд.
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)
А если такой DTO указать в параметрах метода update вместо PostFormRequest, а в самом DTO в конструкторе указать этот самый форм реквест, то контейнер сам все сделает и не нужно писать лишнюю строку в методе. ;)
Не увидел ваш комментарий сразу! Просто гениальная реализация!
какой хитрец)) КРАСАВА!!!
А насчет ДТО для данных из БД.. слышал что и тут их используют. Но как, какой смысл, в чем удобство? у нас же есть и так класс Коллекшен, или выбирать то или другое надо. или из БД в ДТО, потом в колекшен, потом в виде уже выводить... над больше примеров... запутано
Для моделей еще делают, я вроде сказал об этом, так как в моделях тоже не ясно какие поля есть как и в массивах
для моделей из бд там паттерн такой есть. Суть что имплентация Orm, в Ларе Active record. это удобно, быстро писать и... ужасно)))
В больших компаниях с большими продуктами пишущиеся годами, и с большой командой разработчиков это не прокатывает. Потому что требования меняются, поля в базе меняются каждый день, одни утсаревают другие нет, другие только для совместимости, и тебе нужен этот уровень абстракции чтобы навести хоть какой то порядок.
Для этого и делается пародия на нормальную ORM, Data mapper. Когда класс с данными из БД не связан с логикой твоего приложения. Изменилось поле, изменил значение в одном классе и всеее. Кайф) поле было инт стало стринг (для примера), не бегаешь по тысячам строк кода а в одном классе добавляешь каст и всеее))
Data mapper по дефолту в Симфони, и это одна из причин почему для корпоративной разработки рекомендуется Симфони а не Лара.
Вообще орм в ларе такая себе, когда значения в базе становятся 7-8 значными, нужно постоянно следить что там Лара накидала в SQL((( боль
@@CutCodeRu это больные симфонисты, у них ломка без сука сущностей
А субтитры подсказывают что нужно использовать Детей, а не ДТО )
С laravel idea подскажет, что в реквесте на основе rules
если хотите быстро получать помощь - пишите сюда - t.me/laravel_chat
Жаль, что не видно реализации методов класса DTO, которые Вы затем удалили :) Зато поля класса аж на 6 строк :)
т.е. добавляешь новое поле в модель, а потом не забудь его в десятке прослоек тоже добавить
А зачем создавать какой-то специфический DTO, если можно просто геттеры добавить в класс request, вместо дерганья даты напрямую? Не будет лишней статической фабрики в теле контроллера.
Ну тут суть в примере метод validated который возвращает массив и его сконвертировать в обьект и быть уверенным в типах и полях, ситуативно... ролик получился неоднозначным, буду переснимать с другим примером и упрощать подачу
в php8 парамсы из реквеста можно сразу в конструктор дто через ... синтаксис забросить
будет что-то типа такого: $someDto = new SomeDto(...$request->validated());
Пакет от Spatie выглядит перебором, чаще всего кроме toArray ничего и не надо, зачем куча этих методов. И далее если надо то в collect обернул и то же самое..
Да и зачем пакет когда в ide две кнопки нажал и вот тебе дто.
Не понятно как то в чем преимущество, в php8.1 readonly уже будет для ДТО, ещё меньше причин для пакета.
Мб я что то не улавливаю?
Согласен про перебор)
Какой то интерфейс, абстрактный метод...., но как по мне, легче провалиться в класс,или писать php doc...
речь ведь не о классе а о массиве) с классами то все понятно в большинстве случаев (за исключением того же примера в ролике с моделями у которых свойства получены магическими методами и они не явно указаны)
Как раз ознакамливался с этим пакетом от спати
А зачем городить аля из секты симфони мусор если в ларавель реквесты и апи ресурсы и так есть? Это для больных симфони которых вдруг заставили в ларавель писать