Если данные из реквеста использовать прямо в методе контролера, то скорее да, дто не нужен. Но если данные нужно отправить в обработку дальше в сервисный слой, или еще глубже, отправить в очердь, то согласитесь, пихать туда реквест уже смешно :)
Здравствуйте в этом канале очень полезные уроки. Можете подсказать еще о phpDoc в Laravel. Как правильно написать аннотацию к моделу, контроллеру и так дале. Спасибо болшое!
Гляньте в сторону github.com/barryvdh/laravel-ide-helper Сгенерируйте аннотации и посмотрите как это выглядит, а так думаю сниму отдельный ролик на эту тему
Достаточно просто добавить гетеры либо @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() который получает все поля которые участвовали в валидации уже после успешной валидации)) понял?
Как и любой инструмент, о DTO нужно просто знать где оно к месту, а где - нет. А так получается "молотком неудобно доски пилить, поэтому я считаю его бесполезным инструментом и в работе не использую". Один из кейсов, например, где DTO может иметь кроме базовых, также вычисляемые или форматируемые на лету свойства. Но при этом не является сохраняемой в базе моделью. И тогда мы инкапсулируем эту функциональность в DTO и мы красавчики. А ещё например для передачи данных при взаимодействиях между разными модулями и пакетами большого приложения, между разными сервисами микросервисного приложения, для отправки данных в очередь обработки и тд.
Dto используется повседневно во многих кейсах, я же сделал упор на validated в form request как случай когда можно использовать но сам в этом случае не использую, короче запутал и плохо преподнес, пересниму более качественно, спасибо за комментарий
Если нужна подсветка ide, просто приватные свойства пишешь в классе реквеста, и в методе passedValidation присваиваешь. Иногда так делаю, если много потом возни с данными) помню Орвелл говорил что классы реквестов все недооценивают, и не думают о них как о обычных классах. Ни методов туда не пишут ни свойств. Но чаще всего нафиг надо в реквестах это творить))
Не помню сказал или нет в ролике но я на практике dto использую крайне редко, ну а то что можно дописать свойства это само собой, можно выбрать и такой путь) меня как правило и массив не особо пугает)
Я бы сказал, что ДТО все больше начинают использовать на практике, особенно в REST API, где нужно не только из запроса создать ДТО, но и вернуть в ответе как JSON объект. Скорее всего в Ларавеле тоже можно как у Симфони зарезолвить ДТО как аргумент конролера и тогда в контроллер будет прихордить уже готовые данные, в том числе провалидированые
Как это нету, если аргументы контроллера автоматически резолвятся в Ларавеле из IoC контейнера с незапамятных времен. И тайп-хинтнуть можно не только реквест а и вообще любой класс. В том числе и DTO. Ну а если мы тайп-хинтнули наследник FormRequest, то он также будет приходить в контроллер уже провалидированный - разве не это имелось в виду? И что мешает, как тут уже в другом комментарии ответили, класс реквеста превратить в DTO? Для этого достаточно даже не писать в него никакой логики а просто снабдить правильными аннотациями свойств. И в IDE появляются подсказки )
Выпускать видео о DTO и прям в видео говорить что я его не использую это как минимум сразу толкает человека на мысль что это муссорный паттерн. А теперь к паттерну. Основное преимущество в этом паттерне это то что я получаю слепок данных готовый работе с которым я буду 100% уверен что дальше не получу где-то null. Это проявляться когда вы не создаете FormRequest а создаете композицию из данных из раных классов или же источников (ввод, база и тд). И так вы получили набор данных и вам нужно их прокинуть в метод. Раньше это делалось через массив или отдельными аргументами метода. 1) при прокидывании массива это не гарантирует что они там есть, + отсутствие автокомплита. 2) когда мы передаем слепок переменных через аргументы это лочит расширение данного метода в будущем, а так же мы ломает наши юнит тесты и их нужно все переписывать. Прелесть как раз так таки в том что мы описывает набор свойств которые должны в нём быть и гарантированно получаем их в дальнейших экземплярах в которые удобно загружать и расширять. Когда же вы используете массив и прокидываете его дальше по коду и нет такой вероятности что какой нибудь джун случайно не подрежит какой-то ключ или не переопределит его. Всё выше перечисленное относится только к большим проектам там где много разработав, там где естественно важна скорость массивы ваше все.
Но не всегда в больших проектах, встречаются сплошь и рядом, к примеру при работе с api и реализации моделей на основе json данных и особенно актуально при разработке мобильных приложений на других языках программирования
А насчет ДТО для данных из БД.. слышал что и тут их используют. Но как, какой смысл, в чем удобство? у нас же есть и так класс Коллекшен, или выбирать то или другое надо. или из БД в ДТО, потом в колекшен, потом в виде уже выводить... над больше примеров... запутано
для моделей из бд там паттерн такой есть. Суть что имплентация Orm, в Ларе Active record. это удобно, быстро писать и... ужасно))) В больших компаниях с большими продуктами пишущиеся годами, и с большой командой разработчиков это не прокатывает. Потому что требования меняются, поля в базе меняются каждый день, одни утсаревают другие нет, другие только для совместимости, и тебе нужен этот уровень абстракции чтобы навести хоть какой то порядок. Для этого и делается пародия на нормальную ORM, Data mapper. Когда класс с данными из БД не связан с логикой твоего приложения. Изменилось поле, изменил значение в одном классе и всеее. Кайф) поле было инт стало стринг (для примера), не бегаешь по тысячам строк кода а в одном классе добавляешь каст и всеее)) Data mapper по дефолту в Симфони, и это одна из причин почему для корпоративной разработки рекомендуется Симфони а не Лара. Вообще орм в ларе такая себе, когда значения в базе становятся 7-8 значными, нужно постоянно следить что там Лара накидала в SQL((( боль
А если такой DTO указать в параметрах метода update вместо PostFormRequest, а в самом DTO в конструкторе указать этот самый форм реквест, то контейнер сам все сделает и не нужно писать лишнюю строку в методе. ;)
указанные примеры слишком простые чтобы раскрыть преимущества DTO. если у вас сложная логика бизнес модели - то очень даже пригодится, т.к. передавать request везде очень стремно, функции которые принимают реквесты не переиспользуемые. долго расписывать, надеюсь поняли. альтернатива им только массивами все передавать...
А зачем создавать какой-то специфический DTO, если можно просто геттеры добавить в класс request, вместо дерганья даты напрямую? Не будет лишней статической фабрики в теле контроллера.
Ну тут суть в примере метод validated который возвращает массив и его сконвертировать в обьект и быть уверенным в типах и полях, ситуативно... ролик получился неоднозначным, буду переснимать с другим примером и упрощать подачу
в php8 парамсы из реквеста можно сразу в конструктор дто через ... синтаксис забросить будет что-то типа такого: $someDto = new SomeDto(...$request->validated());
Пакет от Spatie выглядит перебором, чаще всего кроме toArray ничего и не надо, зачем куча этих методов. И далее если надо то в collect обернул и то же самое.. Да и зачем пакет когда в ide две кнопки нажал и вот тебе дто. Не понятно как то в чем преимущество, в php8.1 readonly уже будет для ДТО, ещё меньше причин для пакета. Мб я что то не улавливаю?
речь ведь не о классе а о массиве) с классами то все понятно в большинстве случаев (за исключением того же примера в ролике с моделями у которых свойства получены магическими методами и они не явно указаны)
А зачем городить аля из секты симфони мусор если в ларавель реквесты и апи ресурсы и так есть? Это для больных симфони которых вдруг заставили в ларавель писать
