Если данные из реквеста использовать прямо в методе контролера, то скорее да, дто не нужен. Но если данные нужно отправить в обработку дальше в сервисный слой, или еще глубже, отправить в очердь, то согласитесь, пихать туда реквест уже смешно :)
Как и любой инструмент, о DTO нужно просто знать где оно к месту, а где - нет. А так получается "молотком неудобно доски пилить, поэтому я считаю его бесполезным инструментом и в работе не использую". Один из кейсов, например, где DTO может иметь кроме базовых, также вычисляемые или форматируемые на лету свойства. Но при этом не является сохраняемой в базе моделью. И тогда мы инкапсулируем эту функциональность в DTO и мы красавчики. А ещё например для передачи данных при взаимодействиях между разными модулями и пакетами большого приложения, между разными сервисами микросервисного приложения, для отправки данных в очередь обработки и тд.
Dto используется повседневно во многих кейсах, я же сделал упор на validated в form request как случай когда можно использовать но сам в этом случае не использую, короче запутал и плохо преподнес, пересниму более качественно, спасибо за комментарий
Достаточно просто добавить гетеры либо @property аннотации для FormRequest класса. Он и так является DTO, пусть и нарушает SRP, но в Laravel нарушать SRP - это уже давно вариант нормы:)
@@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() который получает все поля которые участвовали в валидации уже после успешной валидации)) понял?
Здравствуйте в этом канале очень полезные уроки. Можете подсказать еще о phpDoc в Laravel. Как правильно написать аннотацию к моделу, контроллеру и так дале. Спасибо болшое!
Гляньте в сторону github.com/barryvdh/laravel-ide-helper Сгенерируйте аннотации и посмотрите как это выглядит, а так думаю сниму отдельный ролик на эту тему
Я бы сказал, что ДТО все больше начинают использовать на практике, особенно в REST API, где нужно не только из запроса создать ДТО, но и вернуть в ответе как JSON объект. Скорее всего в Ларавеле тоже можно как у Симфони зарезолвить ДТО как аргумент конролера и тогда в контроллер будет прихордить уже готовые данные, в том числе провалидированые
Как это нету, если аргументы контроллера автоматически резолвятся в Ларавеле из IoC контейнера с незапамятных времен. И тайп-хинтнуть можно не только реквест а и вообще любой класс. В том числе и DTO. Ну а если мы тайп-хинтнули наследник FormRequest, то он также будет приходить в контроллер уже провалидированный - разве не это имелось в виду? И что мешает, как тут уже в другом комментарии ответили, класс реквеста превратить в DTO? Для этого достаточно даже не писать в него никакой логики а просто снабдить правильными аннотациями свойств. И в IDE появляются подсказки )
Если нужна подсветка ide, просто приватные свойства пишешь в классе реквеста, и в методе passedValidation присваиваешь. Иногда так делаю, если много потом возни с данными) помню Орвелл говорил что классы реквестов все недооценивают, и не думают о них как о обычных классах. Ни методов туда не пишут ни свойств. Но чаще всего нафиг надо в реквестах это творить))
Не помню сказал или нет в ролике но я на практике dto использую крайне редко, ну а то что можно дописать свойства это само собой, можно выбрать и такой путь) меня как правило и массив не особо пугает)
А если такой DTO указать в параметрах метода update вместо PostFormRequest, а в самом DTO в конструкторе указать этот самый форм реквест, то контейнер сам все сделает и не нужно писать лишнюю строку в методе. ;)
А насчет ДТО для данных из БД.. слышал что и тут их используют. Но как, какой смысл, в чем удобство? у нас же есть и так класс Коллекшен, или выбирать то или другое надо. или из БД в ДТО, потом в колекшен, потом в виде уже выводить... над больше примеров... запутано
для моделей из бд там паттерн такой есть. Суть что имплентация Orm, в Ларе Active record. это удобно, быстро писать и... ужасно))) В больших компаниях с большими продуктами пишущиеся годами, и с большой командой разработчиков это не прокатывает. Потому что требования меняются, поля в базе меняются каждый день, одни утсаревают другие нет, другие только для совместимости, и тебе нужен этот уровень абстракции чтобы навести хоть какой то порядок. Для этого и делается пародия на нормальную ORM, Data mapper. Когда класс с данными из БД не связан с логикой твоего приложения. Изменилось поле, изменил значение в одном классе и всеее. Кайф) поле было инт стало стринг (для примера), не бегаешь по тысячам строк кода а в одном классе добавляешь каст и всеее)) Data mapper по дефолту в Симфони, и это одна из причин почему для корпоративной разработки рекомендуется Симфони а не Лара. Вообще орм в ларе такая себе, когда значения в базе становятся 7-8 значными, нужно постоянно следить что там Лара накидала в SQL((( боль
указанные примеры слишком простые чтобы раскрыть преимущества DTO. если у вас сложная логика бизнес модели - то очень даже пригодится, т.к. передавать request везде очень стремно, функции которые принимают реквесты не переиспользуемые. долго расписывать, надеюсь поняли. альтернатива им только массивами все передавать...
Выпускать видео о DTO и прям в видео говорить что я его не использую это как минимум сразу толкает человека на мысль что это муссорный паттерн. А теперь к паттерну. Основное преимущество в этом паттерне это то что я получаю слепок данных готовый работе с которым я буду 100% уверен что дальше не получу где-то null. Это проявляться когда вы не создаете FormRequest а создаете композицию из данных из раных классов или же источников (ввод, база и тд). И так вы получили набор данных и вам нужно их прокинуть в метод. Раньше это делалось через массив или отдельными аргументами метода. 1) при прокидывании массива это не гарантирует что они там есть, + отсутствие автокомплита. 2) когда мы передаем слепок переменных через аргументы это лочит расширение данного метода в будущем, а так же мы ломает наши юнит тесты и их нужно все переписывать. Прелесть как раз так таки в том что мы описывает набор свойств которые должны в нём быть и гарантированно получаем их в дальнейших экземплярах в которые удобно загружать и расширять. Когда же вы используете массив и прокидываете его дальше по коду и нет такой вероятности что какой нибудь джун случайно не подрежит какой-то ключ или не переопределит его. Всё выше перечисленное относится только к большим проектам там где много разработав, там где естественно важна скорость массивы ваше все.
Но не всегда в больших проектах, встречаются сплошь и рядом, к примеру при работе с api и реализации моделей на основе json данных и особенно актуально при разработке мобильных приложений на других языках программирования
А зачем создавать какой-то специфический DTO, если можно просто геттеры добавить в класс request, вместо дерганья даты напрямую? Не будет лишней статической фабрики в теле контроллера.
Ну тут суть в примере метод validated который возвращает массив и его сконвертировать в обьект и быть уверенным в типах и полях, ситуативно... ролик получился неоднозначным, буду переснимать с другим примером и упрощать подачу
в php8 парамсы из реквеста можно сразу в конструктор дто через ... синтаксис забросить будет что-то типа такого: $someDto = new SomeDto(...$request->validated());
речь ведь не о классе а о массиве) с классами то все понятно в большинстве случаев (за исключением того же примера в ролике с моделями у которых свойства получены магическими методами и они не явно указаны)
Пакет от Spatie выглядит перебором, чаще всего кроме toArray ничего и не надо, зачем куча этих методов. И далее если надо то в collect обернул и то же самое.. Да и зачем пакет когда в ide две кнопки нажал и вот тебе дто. Не понятно как то в чем преимущество, в php8.1 readonly уже будет для ДТО, ещё меньше причин для пакета. Мб я что то не улавливаю?
А зачем городить аля из секты симфони мусор если в ларавель реквесты и апи ресурсы и так есть? Это для больных симфони которых вдруг заставили в ларавель писать
![[Full] 4 ต่อ 4 Celebrity EP.922 | 10 พ.ย. 67 | one31](http://i.ytimg.com/vi/zmV5HRIxIBI/mqdefault.jpg)
КОмментарий для поддержки такого красавчика, который пилит годные четкие ясные видео. Респект ❤
@@RuslanMavlyanov благодарю
Отличное объяснение! Спасибо большое!
Спасибо, не знал про это раньше. В принципе, тоже считаю, это дополнительным наслоением. Вряд ли буду использовать)
Но знать надо)
Если данные из реквеста использовать прямо в методе контролера, то скорее да, дто не нужен. Но если данные нужно отправить в обработку дальше в сервисный слой, или еще глубже, отправить в очердь, то согласитесь, пихать туда реквест уже смешно :)
@@PanoOdUa согласен! Сам себя иногда останавливаю от этого 🤣
Спасибо! Не пользуюсь Laravel, но хотя бы стало понятно что такое DTO
Как и любой инструмент, о DTO нужно просто знать где оно к месту, а где - нет. А так получается "молотком неудобно доски пилить, поэтому я считаю его бесполезным инструментом и в работе не использую". Один из кейсов, например, где DTO может иметь кроме базовых, также вычисляемые или форматируемые на лету свойства. Но при этом не является сохраняемой в базе моделью. И тогда мы инкапсулируем эту функциональность в DTO и мы красавчики. А ещё например для передачи данных при взаимодействиях между разными модулями и пакетами большого приложения, между разными сервисами микросервисного приложения, для отправки данных в очередь обработки и тд.
Dto используется повседневно во многих кейсах, я же сделал упор на validated в form request как случай когда можно использовать но сам в этом случае не использую, короче запутал и плохо преподнес, пересниму более качественно, спасибо за комментарий
Лучший ответ под этим видео:)
Я прошу прощения если мой комментарий прозвучал слишком резко ) Не хотел обидеть, хотел просто реально привести примеры где паттерн DTO более к месту.
Мне кажется самописный вариант с классом для 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() который получает все поля которые участвовали в валидации уже после успешной валидации)) понял?
Вообщем можно по разному, здесь озвучен один и вариантов
Здравствуйте в этом канале очень полезные уроки. Можете подсказать еще о phpDoc в Laravel. Как правильно написать аннотацию к моделу, контроллеру и так дале. Спасибо болшое!
Гляньте в сторону github.com/barryvdh/laravel-ide-helper
Сгенерируйте аннотации и посмотрите как это выглядит, а так думаю сниму отдельный ролик на эту тему
Я бы сказал, что ДТО все больше начинают использовать на практике, особенно в REST API, где нужно не только из запроса создать ДТО, но и вернуть в ответе как JSON объект. Скорее всего в Ларавеле тоже можно как у Симфони зарезолвить ДТО как аргумент конролера и тогда в контроллер будет прихордить уже готовые данные, в том числе провалидированые
готовых инструментов в ларавел для этого нет но самостоятельно обвернуть ничего не мешает и сложности в этом нет
нету в Ларе этого((( Но было бы очень круто, надеюсь скопипастят
Как это нету, если аргументы контроллера автоматически резолвятся в Ларавеле из IoC контейнера с незапамятных времен. И тайп-хинтнуть можно не только реквест а и вообще любой класс. В том числе и DTO. Ну а если мы тайп-хинтнули наследник FormRequest, то он также будет приходить в контроллер уже провалидированный - разве не это имелось в виду? И что мешает, как тут уже в другом комментарии ответили, класс реквеста превратить в DTO? Для этого достаточно даже не писать в него никакой логики а просто снабдить правильными аннотациями свойств. И в IDE появляются подсказки )
Если нужна подсветка ide, просто приватные свойства пишешь в классе реквеста, и в методе passedValidation присваиваешь. Иногда так делаю, если много потом возни с данными)
помню Орвелл говорил что классы реквестов все недооценивают, и не думают о них как о обычных классах. Ни методов туда не пишут ни свойств.
Но чаще всего нафиг надо в реквестах это творить))
Не помню сказал или нет в ролике но я на практике dto использую крайне редко, ну а то что можно дописать свойства это само собой, можно выбрать и такой путь) меня как правило и массив не особо пугает)
Не совсем понял, но вроде первый пример, без пакета, остался без валидации. Там валидацию делаем также, как в примере с пакетом?
добрый день! приглашаю в наш чат t.me/laravel_chat, там на вопросы отвечаем быстрее
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 это больные симфонисты, у них ломка без сука сущностей
указанные примеры слишком простые чтобы раскрыть преимущества DTO.
если у вас сложная логика бизнес модели - то очень даже пригодится, т.к. передавать request везде очень стремно, функции которые принимают реквесты не переиспользуемые.
долго расписывать, надеюсь поняли. альтернатива им только массивами все передавать...
Если будет интерес к теме, сделаем более подробный ролик
@@CutCodeRu со всем уважением, но откуда он возьмется елси тема подана как "DTO это обертка над реквестом и нафиг не нужна"?
@@silentage6310 скорее всего переделаю с другим примером и подачей
С laravel idea подскажет, что в реквесте на основе rules
если хотите быстро получать помощь - пишите сюда - t.me/laravel_chat
Выпускать видео о DTO и прям в видео говорить что я его не использую это как минимум сразу толкает человека на мысль что это муссорный паттерн.
А теперь к паттерну. Основное преимущество в этом паттерне это то что я получаю слепок данных готовый работе с которым я буду 100% уверен что дальше не получу где-то null. Это проявляться когда вы не создаете FormRequest а создаете композицию из данных из раных классов или же источников (ввод, база и тд). И так вы получили набор данных и вам нужно их прокинуть в метод. Раньше это делалось через массив или отдельными аргументами метода.
1) при прокидывании массива это не гарантирует что они там есть, + отсутствие автокомплита.
2) когда мы передаем слепок переменных через аргументы это лочит расширение данного метода в будущем, а так же мы ломает наши юнит тесты и их нужно все переписывать.
Прелесть как раз так таки в том что мы описывает набор свойств которые должны в нём быть и гарантированно получаем их в дальнейших экземплярах в которые удобно загружать и расширять.
Когда же вы используете массив и прокидываете его дальше по коду и нет такой вероятности что какой нибудь джун случайно не подрежит какой-то ключ или не переопределит его.
Всё выше перечисленное относится только к большим проектам там где много разработав, там где естественно важна скорость массивы ваше все.
Четко сказано
Но не всегда в больших проектах, встречаются сплошь и рядом, к примеру при работе с api и реализации моделей на основе json данных и особенно актуально при разработке мобильных приложений на других языках программирования
Я в ролике имел ввиду что не использую для form request
Но в целом ролик вышел не понятный и с множеством вопросом, скорее всего сделаю новую версию)
@@CutCodeRu так же стоит добавить что с новой версией PHP это уже будет в нём самом.
Всё равно, спасибо за труд.
т.е. добавляешь новое поле в модель, а потом не забудь его в десятке прослоек тоже добавить
Жаль, что не видно реализации методов класса DTO, которые Вы затем удалили :) Зато поля класса аж на 6 строк :)
А зачем создавать какой-то специфический DTO, если можно просто геттеры добавить в класс request, вместо дерганья даты напрямую? Не будет лишней статической фабрики в теле контроллера.
Ну тут суть в примере метод validated который возвращает массив и его сконвертировать в обьект и быть уверенным в типах и полях, ситуативно... ролик получился неоднозначным, буду переснимать с другим примером и упрощать подачу
в php8 парамсы из реквеста можно сразу в конструктор дто через ... синтаксис забросить
будет что-то типа такого: $someDto = new SomeDto(...$request->validated());
Какой то интерфейс, абстрактный метод...., но как по мне, легче провалиться в класс,или писать php doc...
речь ведь не о классе а о массиве) с классами то все понятно в большинстве случаев (за исключением того же примера в ролике с моделями у которых свойства получены магическими методами и они не явно указаны)
Пакет от Spatie выглядит перебором, чаще всего кроме toArray ничего и не надо, зачем куча этих методов. И далее если надо то в collect обернул и то же самое..
Да и зачем пакет когда в ide две кнопки нажал и вот тебе дто.
Не понятно как то в чем преимущество, в php8.1 readonly уже будет для ДТО, ещё меньше причин для пакета.
Мб я что то не улавливаю?
Согласен про перебор)
Как раз ознакамливался с этим пакетом от спати
А зачем городить аля из секты симфони мусор если в ларавель реквесты и апи ресурсы и так есть? Это для больных симфони которых вдруг заставили в ларавель писать