У ДТО есть ответственность, типизировать данные при передаче их между слоями, не писать в них бизнес логику, не валидировать, не делать респонс. Если фреймворк рекомендует что-то, то наверно не просто так, наверно чтобы была преемственность и проекты на ларавел не превращались в мусорку. Но есть учители, которые навязывают свое субъективное мнение
Обожаю челов, которые недавно узнали за солид и с умным видом пытаются нести ахинею. То есть, если мы декомпозируем dto на отдельные классы валидации и отдельные коассы типизации параметров, то мусора меньше станет? Мне кажется наоборот его больше станет, это ненужное усложнение только усложняет отлаживание кода в будущем
@@mihaivanov8569 Милый мой хороший, мне глубоко индифферентно кого ты там обожаешь, ты улови суть, если разрабы php не будут следовать нотации хотя бы внутри одного фреймворка, то языку не выйти на уровень доверия даже питона или js. А конкретно ты можешь писать, как угодно и что угодно, не жалко
@@mihaivanov8569 dto это просто чтобы представить данные из одного вида в другой. Валидацию нужно делать отдельно до передачи в dto. Если писать в одном классе, то со временем превратится в большую проблему
Так если у тебя DTO, то какая тебе разница что там на слое фреймворка или в базе данных происходит. По сути, ты можешь даже выкинуть лару и код бизнес-процессов запустить в другом фреймворке или вообще без фреймворка.
@@mishafomin3973 Data Transfer Object должен передавать данные между слоями приложения. Разные слои приложения могут быть написано по-разному и работать с разными наборами данных, а задача DTO как раз в том, чтобы подружить слой бизнес-логики со слоем фреймворка, передавая данные между ними. По сти это эволюция паттернов Прокси, Адаптер и может даже Фасад (но это не точно). Будет ли он использовать ORM или QueryBuilder не так важно. Важно, что он отвязывает структуру сущности бизнес-процесса от ее структуры хранения в базе. Не знаю как проще это объяснить
@@mclotos Должно, но не обязано) Как часто вам приходилось менять базу данных, ORM за время работы? P.S. сам я использую DTO только для того, чтобы сгруппировать несколько параметров для сервис-класса, а на выходе уже идет модель
@@NK-kg1qv ну у меня есть несколько компонентов проекта, которые пару раз переезжали на другой фреймворк. Просто они очень древние) ну и я не говорю о смене бд, а только о смене структур - поля переезжают из таблицы в таблицу, связи меняются, но это не должно влиять на БП
Видео полезное, но не отвечает на вопрос "А что, если не JsonResource" ? Какая альтернатива по архитектуре? Ведь зачастую бывает так, что то, что приходит и возвращается из Service-слоя не совпадает с тем, что нужно отправить обратно. Как назвать такие слои и как организовать структуру папок? Я пока использую JsonResource именно для возврата на Frontend данные, но все чаще приходит на ум вернуть обычный массив. По Laravel-Data как-то слабовато. Там есть и Paginate, и урезанный Dto(вместо Data, отличия в трейтах только), и трейты, которые добавляют функционал.
Я юзаю для ответов джейсонресурси а для бизнеслогиги дто. И кайфую 😊
За видос спасибо
я тоже, но вот как раз начинаются проблемы когда нужно что-то в ресурсах делать этих. теперь задумался и на ответы DTOхи делать вместо ресурсов
Спасибо за ролик!
У ДТО есть ответственность, типизировать данные при передаче их между слоями, не писать в них бизнес логику, не валидировать, не делать респонс. Если фреймворк рекомендует что-то, то наверно не просто так, наверно чтобы была преемственность и проекты на ларавел не превращались в мусорку. Но есть учители, которые навязывают свое субъективное мнение
@@KDenisG наверно)
Обожаю челов, которые недавно узнали за солид и с умным видом пытаются нести ахинею. То есть, если мы декомпозируем dto на отдельные классы валидации и отдельные коассы типизации параметров, то мусора меньше станет?
Мне кажется наоборот его больше станет, это ненужное усложнение только усложняет отлаживание кода в будущем
@@mihaivanov8569 Милый мой хороший, мне глубоко индифферентно кого ты там обожаешь, ты улови суть, если разрабы php не будут следовать нотации хотя бы внутри одного фреймворка, то языку не выйти на уровень доверия даже питона или js. А конкретно ты можешь писать, как угодно и что угодно, не жалко
@@mihaivanov8569 dto это просто чтобы представить данные из одного вида в другой. Валидацию нужно делать отдельно до передачи в dto. Если писать в одном классе, то со временем превратится в большую проблему
Так если у тебя DTO, то какая тебе разница что там на слое фреймворка или в базе данных происходит. По сути, ты можешь даже выкинуть лару и код бизнес-процессов запустить в другом фреймворке или вообще без фреймворка.
@@mclotos так точно
Так а как лучше на ваше мнение? Чисто дто или чтоб дто имплементил или екстендил какой-то полезный класс с плюшками из ларавельных?
@@mishafomin3973 Data Transfer Object должен передавать данные между слоями приложения. Разные слои приложения могут быть написано по-разному и работать с разными наборами данных, а задача DTO как раз в том, чтобы подружить слой бизнес-логики со слоем фреймворка, передавая данные между ними. По сти это эволюция паттернов Прокси, Адаптер и может даже Фасад (но это не точно). Будет ли он использовать ORM или QueryBuilder не так важно. Важно, что он отвязывает структуру сущности бизнес-процесса от ее структуры хранения в базе.
Не знаю как проще это объяснить
@@mclotos Должно, но не обязано) Как часто вам приходилось менять базу данных, ORM за время работы?
P.S. сам я использую DTO только для того, чтобы сгруппировать несколько параметров для сервис-класса, а на выходе уже идет модель
@@NK-kg1qv ну у меня есть несколько компонентов проекта, которые пару раз переезжали на другой фреймворк. Просто они очень древние)
ну и я не говорю о смене бд, а только о смене структур - поля переезжают из таблицы в таблицу, связи меняются, но это не должно влиять на БП
Если есть, значит можно использовать. В чем проблема? Куча методов на фильтрацию атрибута в ресурсе это плохо?
@@Seraf_ используйте, кто ж мешает) я не использую а позицию обьяснил
Видео полезное, но не отвечает на вопрос "А что, если не JsonResource" ?
Какая альтернатива по архитектуре?
Ведь зачастую бывает так, что то, что приходит и возвращается из Service-слоя не совпадает с тем, что нужно отправить обратно.
Как назвать такие слои и как организовать структуру папок?
Я пока использую JsonResource именно для возврата на Frontend данные, но все чаще приходит на ум вернуть обычный массив.
По Laravel-Data как-то слабовато. Там есть и Paginate, и урезанный Dto(вместо Data, отличия в трейтах только), и трейты, которые добавляют функционал.
@@NK-kg1qv этот вопрос мы разбираем на курсе где не используем jsonresource, да и laravel data тоже
Привет. Давно смотрю, во многом помог, научил. Но сегодня было тяжело слушать произношение «DTO»