Приношу извинения разработчикам с "АСиКью ТикТокера", изо всех сил пытался говорить кратко - не вышло. Сорямба. тиктокеры - го в тикток. Остальным - приятного просмотра! 👍
the best author ever! Спасибо большое за видосик!!! По видосеку увидел, что Махмуд в апиато контроллерах не пробрасывает реквест, а делает деструктуризацию реквеста и передает его как простыми параметрами функций, т.е. по сути это ок, т.к. все остальная логика методов реквеста "купируется" в контроллере и не передается дальше по моделям. А заменить потом примитивы на dto на порядок проще, чем копаться с реквестом в моделя, так что no worries, думаю что дто туда или вернется или появится какая-то моделька. DTO можно юзать как метод борьбы с плохим кодом в процессе рефакта, в частности с "одержимостью примитивами" (Фаулер). Но на этапе проектирования и кодирования я бы конечно избегал юзания dto в пользу полноценных моделек
Привет Дмитрий! Сижу смотрю видео и вспоминаю, как 6 лет назад делал первые шаги в программировании и учил php по вашему курсу с магазином. На данный момент работаю Senior Angular Developer в епаме, сам организовываю уже 3-ти курсы у себя в небольшом городе, и хорошо зарабатываю. Хочу Вам во-первых сказать СПАСИБО!!! Что делитесь такой ценной информацией. И второе: что 6 лет назад что сейчас ваши видео очень полезны!
Очень содержательное видео с конструктивным разбором и советами применения, спасибо большое! DTO используется наряду с Порто на моем месте работы, в одном из Ташкентских финтехов. Ваши видео кстати входят в обязательное ознакомление в онбординге бекенд разработчиков 😁. Всех благ, не пропадайте
Дим, спасибо большое за твой контент, очень круто. По поводу бритвы Окамме и того, что когда использовать или не использовать по необходимости, с опытом я пришел к выводу, что единообразие подходов в проекте важнее, ибо когда разработчик видит разные релизации и подходы в одном проекте, это пораждает лишнюю когнитивную нагрузку, поэтому я как тим лид сейчас делаю строго круглое кати квадратное неси, мы выбираем подход единый и используем по всему проекту, выбрали ДТО, просто берем и делаем так всегда, выбрали разделение на команды и запросы, значит делаем так всегда и т.д, насчет сложности, сложность = незнание, поэтому мы устраняем незнание, объясняем и делаем код ревью где все разработчики подтягиваются до нужного уровня понимания, сложность уходит
Ахаха, Дмитрий, видео огонь! Четко, понятно и с юмором, как всегда! Спасибо, что озвучил свое мнение про проброс реквестов в Апиато. А то я аж присел от неожиданности, когда увидел в 10й версии пропихивание реквеста в Action)).
38:56 вот не соглашусь с передачей модельки вместо создания её ДТОшной копии. У модели поведение, метод, в который её передают, возьмёт и изменит её состояние через её публичные методы (может, сегодня их нет, завтра добавят, послезавтра забудут, что они значат, а ещё через 3 дня новый девелопер, работающий с подсистемой, куда передали эту модель, возьмёт и дёргнет эти методы, а почему бы и нет, ему же её передали с методами, значит можно дёргать, он формально прав). DTO пресекает эту проблему на корню
Здравствуйте! Смотрел ранее ваши видео про Ларавель, за них отдельное спасибо! В начале месяца нашёл свою первую работу в должности разработчика. Без Ларавеля, но на чистом PHP. Попросили изучить DTO и ваше видео прям вовремя вышло. Спасибо за труд!
Дмитрий, если позволите, задам вопрос. Из статьи на вики: "The difference between data transfer objects and business objects or data access objects is that a DTO does not have any behavior except for storage, retrieval, serialization and deserialization of its own data (mutators, accessors, parsers and serializers)." Почему мутаторы, аксессоры и парсеры стоят в одном ряду с сериализацией? Ведь первые как раз таки про логику приложения, тогда как сериализация допустима в DTO.
Нет, какая же это логика приложения? Аксессор выдаст те же данные в нужном формате. Например из доки лары про аксессоры - всего лишь первую букву значения свойства делает заглавной.
Спасибо, Дмитрий! Думал, что забили уже на канал. Мне нравится стиль представления. Пусть там даже прибалтийские акценты будут. Как начинающему, конечно трудновато после просмотра Вашего курса по Ларавель год назад, где всё расжёвывалось с 0-ля, и практикуясь на своих пробных проектах, вникать в шаблоны - сразу большой скачок между уровнями. И, даже немного с опаской ждал новых видео, потому, что каждое показывало сколько ещё всего необходимо изучить и прочувствовать самому на практике. Вот уже тоже приходилось передавать в объекты целые массивы, что оказалось дурной практикой. Теперь, благодаря уроку буду использовать DTO.
Спасибо за ролик. В книге "Чистая Архитектура" есть тема про проведение границ. И там упоминалось, что не смотря на то, что поток исполнения идет от контроллера к модели. Модель более важная, так как содержит бизнес логику и должна защищаться от контроллера. Именно поэтому проводится граница между контроллером и операционным слоем (Application layer) и тут используется DTO для передачи данных. Мне кажется это важный нюанс, что DTO используется для передачи данных именно между слоями, и это не относится ко всем службам в целом. Для некого калькулятора, период дат скорее является Value Object-ом, а не DTO. Не стоит их путать. В конструкторе периода дат мы можем добавить какие-нибудь проверки и выкинуть исключение + повторно использовать и прокидывать в разные методы.
Пожалуйста, воздержитесь от пародирования, я о выражениях «ээ шайтанама» и прочих. Вам просто не идёт это)) В остальном благодарность, полезные видео у вас 👍
Дмитрий, спасибо за интересное видео, с удовольствием посмотрел) Отдельное спасибо за разбор либы. Это интересно. Можете рассказать, а в чем отличие DTO от ValueObject?
Вот я головой понимаю, что почитать про dto можно на хабре причем ты потратишь 5 минут. Я трачу 41 минуту. Все же классно , Дмитрий, ты рассказываешь :)
ох ёёпт! кто проявился... пол года не было, наверно... работы только наверное много.. пропадаешь так.. я так хотел по твоим видосам освоить пхп и ооп и ларавель и всё остальное... но проклятый джаваскрипт пришОл и всё испортил :-) хотя шаблоны проектирования можно просмотреть наверное.. вот нагрузка джуновская спадёт и займусь. А ты пили видосы хоть иногда! мол жив здоров.. :-) удачи!
Не хочу быть душнилой, но 1) не SPR(эспэр), а SRP (эсэрпи). 2) static function createFromArray(...) - статическая фабрика 3) никогда не слышал, чтобы статические фабрики нарушали SRP. Сказать, что статическая фабрика нарушает SRP - то же самое, что сказать, что SRP нарушается перегрузкой конструктора в той же Java. 4) классы-фабкири DTO объектов называются DtoAssembler-ами и служат чем-то вроде внешнего конструктора для DTO, у которого все свойства публичны 5) инкапсуляция - не сокрытие данных, а процесс соблюдения инвариантов А в целом рад, что такие ролики выходят в русском сегменте Сети. Ты первый, на кого я наткнулся, кто сказал о том, что конструкторы и приватные доступы к свойствам зачастую лишние. Это круто
Dto4 я описываю $fields = ["id", "name", "addres".... ]; поля в массиве, и потом просто по нему пробегают, тоже самое что и у полей класса брать, но более явно :)
... здесь мы нарушаем принцип единственной ответственности ... ))) да блин, ну давайте уже примем за факт что этот принцип все всегда нарушают в той или иной степени. мир праху SRP )
Не вижу сложностей в соблюдении SRP. Зато видел много сложностей в поддержке кода когда его не соблюдали. Нарушать его можно только при полном понимании последствий.
@@DmitryAfanasyev да согласен в целом, просто с срп растет не файл или класс, а количество файлов. В которых классы делающие чтото одно, как просто так и сложно можно сделать и так и так. Надо делать просто
Как потом DTO использовать / преобразовать дальше модель для дальнейшей передачи в другие сервисы? По моему мнению никакой другой сервис, кроме того сервиса, куда мы первично передали DTO не знает и не должен знать что такое DTO, а это означает, что для дальнейшей передачи DTO уже как модели, нужно создать еще одну фабрику. Делать 2 фабрики? (Первая - из request в DTO, а потом вторую фабрику из DTO в модель) Например, хочется использовать DTO, когда мы проксируем запросы пользователя (тонкая модель, меньше свойств, название свойств отличается) в другой микросервис REST API ( у него толстая модель, больше свойств)
Сразу использовать. Часть данных может стать свойствами принимающего объекта, часть данных будет передана в подобъекты получателя и тп. Главное унифицировать, регламинтировать, оптимизировать передачу/получение. Если оно того стоит.
Вопрос пока-что не дающий мне покоя) В видосе показан пример DTO только с одной структурой данных, допустим, с тем же продуктом. У продукта мы знаем список полей. Ну и допустим, мы можем забубенить их самым примитивным способом как публичные в классе и передавать. А что делать, когда таких структур данных больше? Не только продукт, а еще и, допустим, комментарий, билет на поезд, заявка с формы обратной связи, и так далее. - Под каждую структуру делать свой объект DTO, тем самым их размножая под каждую сущность? - Или обойтись одним объектом, но которому можно динамически задавать поля? Но если это будет один объект с динамическими полями, как тогда убедиться, что в бизнес логику ушла именно нужная структура? Шо делать :D
Сделать эту структуру в олном классе. Динамические поля точно не надо - лишаемся контроля. Свойства являющиеся доугими dto формально считаются лишним усложнением.
Спасибо! Дмитрий, скажите, а репозитории, описанные в курсе по Laravel, и сервисный слой, это одно и то же (т.к. в некоторых проектах сервисы выполняют и функции работы с БД) или их можно использовать одновременно в контроллерах?
Дмитрий! Очень нравятся твои видео про шаблоны проектирования, спасибо за то что они есть, я понял некоторые вещи благодаря тебе) Ты проделал большую и ценную работу, обязательно поддержу тебя рублём) Есть два вопроса: 1) Porto (apiato) open source, так? Ты не думал поучаствовать в этом проекте? Вроде ты здорово разобрался, используешь его в работе и тд, мог бы внести ценный вклад) 2) К чему акцент и быдло манера в объяснениях? Это местами забавно, но то ли с подачей что-то, то ли слишком часто используется, начало резать ухо.. Складывается впечатление, что это намёк на целевую аудиторию "быдло объяснения для быдлокодеров" :D (это больше обратная связь от одного отдельного человека, чем вопрос)
Автор рассказывает разумные вещи, мне интересно наблюдать. Но я не согласен с его видением сервисного слоя. Есть сервисы, а есть сервис провайдеры, зачем нагружать свой di
А как вы называете объекты-сущности? И используете ли вообще такой подход? Например, есть DTO - которые собирают набор данных в группу для передачи, есть Model (Laravel) или Entity (Sympfony) - которая описывает данные в БД. Но как быть, когда нам нужно собрать данные в структуру для понятной и удобной работы. Например: $armor = new Armor(); $armor->setCurrentCapacity(95); $passenger = new Passenger(); $passenger->setName('Artem'); $passenger->setType(PASSENGER_TYPE::CIVIL); $passenger->setArmor($armor); $car = new Car(); $car->addPassenger($passenger); и допустим эти объекты могут иметь еще с несколько десятков параметров каждый. И допустим ожидается, что планируется еще расширять их в будущем, добавляя новые сущности, например new Weapon(). Добавлять абстракции, когда нам понадобиться несколько видов Armor, несколько видов Passenger и несколько видов Car. Чем в таком случае являются объекты Car, Passenger, Armor и в другие ? Model или DTO или что-то третье? Думаю это точно не модель описывающая БД. (Хотя теоретически она может и описывать данные из БД). На DTO это похоже, но DTO представляется несколько проще. Поэтому всегда кажется, что это что-то третье. Но что не могу определить.
30:20 я это понял, когда еще mixin для scss/sass писал. это жопа когда у тебя больше 3-х параметров ... Я конечно встречал, когда в функцию передавали по 13-20 параметров ... я думал где они руки пропили ...
Dto3 вариант, вот тоже начитаешься этих DDDшников, иммутабельность ) начинаешь все это вот так упаковывать, столько лишнего кода, спрашиваешь себя зачем все это? )))
DTO только в котроллерах будет использоваться? Ты хочешь вместо прокидывания параметров передать $request. Я бы не стал делать так потому что контекст может отличаться. Например клиент вводит в форму какие то данные, мы получим обьект $request соответствующий, но вдруг нам стало нужно создать excel документ и контекст совсем другой уже, мы не ждем $request от кого либо и мы просто хотим передать параметры такие же какие могли бы быть в $request. Твой подход способствует дублированию кода.
@@DmitryAfanasyev на 38 минуте ты сказал "если нет времени может быть можно поставить эту заплатку, может быть это лучше чем передовать 10 параметров в методе". На самом деле не лучше, в первую очередь дублирование искоренять нужно, а потом о параметрах заботится, я это хотел сказать. Параметры вообще такая замарочистая фигня, я лично в работе не парюсь особо за параметры, и не чего страшного не происходит, а вот дублирование очень сильно может испортить жизнь, так как если нужно будет внести правки их придется вносить во все дубли, а ведь можно забыть это сделать и тогда будут косяки которые всплывут не сразу.
@@davidlakazov9156 "Ты хочешь вместо прокидывания параметров передать $request" Нет, я этого не говорил и не хочу и не советую. Посмотрел 38ю минуту - нет там таких советов. Ты выдумал некую проблему и списал её на меня..... Либо посмотри внимательнее, походу ты что-то не так понял.
Вопрос не по данному видео. На что можно заменить 302 код ответа? Не аякс. Ну например после создания - 201 код можно, а при обновлении, удалении? А то 302 код кэшируется, вот уже 3й раз с ним попадаюсь. то браузер пропускает запрос, а идет далее. Или в Телескоп в Сессии есть success сообщение, но блейд якобы его не видит. Обновляю страницу и еще раз добавляю запись - сообщение с success начинает видеть
@@chincharovpc4120 ну для обновления 200 не шло - ругалось, что 200 не для редиректа. Короче оставил по умолчанию, там для тестового задания по быстрому склепал, без аякса, только удаление на аякс, чтоб в списке не тулить формы
@@DmitryAfanasyev та вроде не было его в апиато. По крайнее мере вы описывали некий пакет pdo в апиато, и охарактеризовали его как нечто адски страшное. У спати пакет прост как гречка, там даже документация на него вмещается на одной странице А4)))
Возник вопрос тока не ругай меня я в этом ещё новичок. Считается если ли нарушением если DTO наследуется от другого класса?. Например создал класс BaseDTO там я описал несколько магических методов которые могут повторятся такие как получение данных в разных форматов toArray, создание данных из реквеста моделей и тд и уже ProductDTO extends BaseDTO по сути закон многократного использования сохранятся
Если в базовый класс вынесены методы представления собственных данных, то норм. Дто содеожащий свойство которое тоже дто - это уже не норм. Забыл об этом упомянуть.
Лучше делать так как самому интересно. Ибо как ни старайся придерживаться той или иной концепции - всегда будут не довольные. По этому надо делать "вкайф".
@@DmitryAfanasyev я писал, что единственное как можно связать ДТО с анти-паттерном, это анти-паттерн data class. Но сам дядя Боб писал, что есть исключения и data-class не всегда анти-паттерн (Refactoring, 83 стр.)
Приношу извинения разработчикам с "АСиКью ТикТокера", изо всех сил пытался говорить кратко - не вышло. Сорямба. тиктокеры - го в тикток.
Остальным - приятного просмотра! 👍
the best author ever!
Спасибо большое за видосик!!!
По видосеку увидел, что Махмуд в апиато контроллерах не пробрасывает реквест, а делает деструктуризацию реквеста и передает его как простыми параметрами функций, т.е. по сути это ок, т.к. все остальная логика методов реквеста "купируется" в контроллере и не передается дальше по моделям. А заменить потом примитивы на dto на порядок проще, чем копаться с реквестом в моделя, так что no worries, думаю что дто туда или вернется или появится какая-то моделька.
DTO можно юзать как метод борьбы с плохим кодом в процессе рефакта, в частности с "одержимостью примитивами" (Фаулер).
Но на этапе проектирования и кодирования я бы конечно избегал юзания dto в пользу полноценных моделек
Получил архитектурное удовлетворение от просмотра видео! Означает ли это, что мой АСиКью хотя бы чуть выше тиктокера?!
Привет Дмитрий! Сижу смотрю видео и вспоминаю, как 6 лет назад делал первые шаги в программировании и учил php по вашему курсу с магазином. На данный момент работаю Senior Angular Developer в епаме, сам организовываю уже 3-ти курсы у себя в небольшом городе, и хорошо зарабатываю. Хочу Вам во-первых сказать СПАСИБО!!! Что делитесь такой ценной информацией. И второе: что 6 лет назад что сейчас ваши видео очень полезны!
Благодарю за отзыв! Очень рад что у вас все хорошо сложилось! Успехов в дальнейшем! 🙏
Спасибо, что не забываешь о нас👍
Как всегда приятно тебя видеть. Все четко по теме👍
Канал в массы. Спасибо за труд.
Спасибо за видео. Приятно что выпуски продолжают выходить, всегда смотрю с удовольствием )))
Нормальный формат, главное всё доступно и не обрывается на полуслове и нет недосказанности.
Очень содержательное видео с конструктивным разбором и советами применения, спасибо большое! DTO используется наряду с Порто на моем месте работы, в одном из Ташкентских финтехов. Ваши видео кстати входят в обязательное ознакомление в онбординге бекенд разработчиков 😁. Всех благ, не пропадайте
Остроумно, весело, содержательно, ёмко, актуально ☝️.
Дим, спасибо большое за твой контент, очень круто. По поводу бритвы Окамме и того, что когда использовать или не использовать по необходимости, с опытом я пришел к выводу, что единообразие подходов в проекте важнее, ибо когда разработчик видит разные релизации и подходы в одном проекте, это пораждает лишнюю когнитивную нагрузку, поэтому я как тим лид сейчас делаю строго круглое кати квадратное неси, мы выбираем подход единый и используем по всему проекту, выбрали ДТО, просто берем и делаем так всегда, выбрали разделение на команды и запросы, значит делаем так всегда и т.д, насчет сложности, сложность = незнание, поэтому мы устраняем незнание, объясняем и делаем код ревью где все разработчики подтягиваются до нужного уровня понимания, сложность уходит
Спасибо, очень понятно, интересно и на примерах.
Дима, спасибо за видео, как всегда всё по полочкам
После 25 минуты можно выключать. Спасибо за видос!
прослушал первые 10 сек. подписался. можно вот этого вот почаще
Спасибо Дмитрий все по делу, так держать и не пропадай, давай больше видео, ты нас мотивируешь
Нарезки в начале просто бомба)
Все четко! Создателю респект и благ!
Дмитрий , не пропадай.
У тебя качественный контент
Отличный урок, очень доступное объяснение =) Спасибо)
🙏
Ахаха, Дмитрий, видео огонь! Четко, понятно и с юмором, как всегда! Спасибо, что озвучил свое мнение про проброс реквестов в Апиато. А то я аж присел от неожиданности, когда увидел в 10й версии пропихивание реквеста в Action)).
38:56
вот не соглашусь с передачей модельки вместо создания её ДТОшной копии. У модели поведение, метод, в который её передают, возьмёт и изменит её состояние через её публичные методы (может, сегодня их нет, завтра добавят, послезавтра забудут, что они значат, а ещё через 3 дня новый девелопер, работающий с подсистемой, куда передали эту модель, возьмёт и дёргнет эти методы, а почему бы и нет, ему же её передали с методами, значит можно дёргать, он формально прав). DTO пресекает эту проблему на корню
Дмитрий, спасибо вам огромное!
О, чувак, ты запилил видос про ДТО))) Классно, спасибо))
Спасибо за видео.Коммент в поддержку!
Ураа, Дмитрий вернулся )
Здравствуйте! Смотрел ранее ваши видео про Ларавель, за них отдельное спасибо! В начале месяца нашёл свою первую работу в должности разработчика. Без Ларавеля, но на чистом PHP. Попросили изучить DTO и ваше видео прям вовремя вышло. Спасибо за труд!
Дмитрий, если позволите, задам вопрос. Из статьи на вики: "The difference between data transfer objects and business objects or data access objects is that a DTO does not have any behavior except for storage, retrieval, serialization and deserialization of its own data (mutators, accessors, parsers and serializers)." Почему мутаторы, аксессоры и парсеры стоят в одном ряду с сериализацией? Ведь первые как раз таки про логику приложения, тогда как сериализация допустима в DTO.
Нет, какая же это логика приложения? Аксессор выдаст те же данные в нужном формате. Например из доки лары про аксессоры - всего лишь первую букву значения свойства делает заглавной.
Спасибо большое за видос, когда увидел что вышел видос, посмотрел в зеркало, борода еще не выросла👍
Дмитрий вернулся, круть :)
Спасибо. Все чётко и понятно.
Спасибо, Дмитрий! Думал, что забили уже на канал. Мне нравится стиль представления. Пусть там даже прибалтийские акценты будут. Как начинающему, конечно трудновато после просмотра Вашего курса по Ларавель год назад, где всё расжёвывалось с 0-ля, и практикуясь на своих пробных проектах, вникать в шаблоны - сразу большой скачок между уровнями. И, даже немного с опаской ждал новых видео, потому, что каждое показывало сколько ещё всего необходимо изучить и прочувствовать самому на практике. Вот уже тоже приходилось передавать в объекты целые массивы, что оказалось дурной практикой. Теперь, благодаря уроку буду использовать DTO.
подача и сам материал просто 100 лвл
p.s. 40:10 "kepp it stupid"ахахааххаха прорвало
Сначала лайк, потом глядеть)
🙏
Спасибо :) очень интересно получилось.
Нужен ролик-сборник всех интро к урокам. Будет бомба. Спасибо за уроки!
Лайк заслуженный
За 'чапалах' - отдельный лайк)
Ощущение, что DTO нужен, чтобы массивчики посильнее типизировать
Спасибо за ролик.
В книге "Чистая Архитектура" есть тема про проведение границ. И там упоминалось, что не смотря на то, что поток исполнения идет от контроллера к модели. Модель более важная, так как содержит бизнес логику и должна защищаться от контроллера. Именно поэтому проводится граница между контроллером и операционным слоем (Application layer) и тут используется DTO для передачи данных. Мне кажется это важный нюанс, что DTO используется для передачи данных именно между слоями, и это не относится ко всем службам в целом.
Для некого калькулятора, период дат скорее является Value Object-ом, а не DTO. Не стоит их путать. В конструкторе периода дат мы можем добавить какие-нибудь проверки и выкинуть исключение + повторно использовать и прокидывать в разные методы.
Да, под периодом я не дто имел в виду.
Спасибо больше за видео
DTO иммутабельный, поэтому наличие аксессоров - норма. А с повлением readonly все стало проще.
Дмитрий, что-то Вас давно не было, с возвращением)))
🙏
Пожалуйста, воздержитесь от пародирования, я о выражениях «ээ шайтанама» и прочих. Вам просто не идёт это))
В остальном благодарность, полезные видео у вас 👍
Я родом из Узбекистана - мне можно 😉. Благодарю!
Дмитрий, спасибо за интересное видео, с удовольствием посмотрел) Отдельное спасибо за разбор либы. Это интересно.
Можете рассказать, а в чем отличие DTO от ValueObject?
Спасибо за видео
Просто Топ, лучше не найти
Вот я головой понимаю, что почитать про dto можно на хабре причем ты потратишь 5 минут. Я трачу 41 минуту. Все же классно , Дмитрий, ты рассказываешь :)
29:10 Привет из будущего хоть и не далекого=) Проверил все также как на видео) ПлёхА =(
А если по факту, то мне понравился паттерн и я его реализую в своем проекте, СПАСИБО
Я жду твои видео как дед мороза на новый год!))))
Спасибо!
ох ёёпт! кто проявился... пол года не было, наверно... работы только наверное много.. пропадаешь так..
я так хотел по твоим видосам освоить пхп и ооп и ларавель и всё остальное... но проклятый джаваскрипт пришОл и всё испортил :-)
хотя шаблоны проектирования можно просмотреть наверное.. вот нагрузка джуновская спадёт и займусь. А ты пили видосы хоть иногда! мол жив здоров.. :-) удачи!
Летом не зотелось много времени ща пк проводить. Да и на работе сильные перемены произошли - адаптация еще в процессе.
Не хочу быть душнилой, но
1) не SPR(эспэр), а SRP (эсэрпи).
2) static function createFromArray(...) - статическая фабрика
3) никогда не слышал, чтобы статические фабрики нарушали SRP. Сказать, что статическая фабрика нарушает SRP - то же самое, что сказать, что SRP нарушается перегрузкой конструктора в той же Java.
4) классы-фабкири DTO объектов называются DtoAssembler-ами и служат чем-то вроде внешнего конструктора для DTO, у которого все свойства публичны
5) инкапсуляция - не сокрытие данных, а процесс соблюдения инвариантов
А в целом рад, что такие ролики выходят в русском сегменте Сети. Ты первый, на кого я наткнулся, кто сказал о том, что конструкторы и приватные доступы к свойствам зачастую лишние. Это круто
Годно, единственное удобней смотреть в скорости воспроизведения 1.5 так как все очень медленно на 1.
Ребят у меня не было времени сделать это видео короче, поэтому я сделал его длинее. Никлаус Вирт =)
Dto4 я описываю $fields = ["id", "name", "addres".... ]; поля в массиве, и потом просто по нему пробегают, тоже самое что и у полей класса брать, но более явно :)
Спасибо
Ура Ура Ура
... здесь мы нарушаем принцип единственной ответственности ... ))) да блин, ну давайте уже примем за факт что этот принцип все всегда нарушают в той или иной степени. мир праху SRP )
Не вижу сложностей в соблюдении SRP. Зато видел много сложностей в поддержке кода когда его не соблюдали. Нарушать его можно только при полном понимании последствий.
@@DmitryAfanasyev да согласен в целом, просто с срп растет не файл или класс, а количество файлов. В которых классы делающие чтото одно, как просто так и сложно можно сделать и так и так. Надо делать просто
29 минута - теперь вместо реквеста в метод пробрасывается массив обыкновенный
Как потом DTO использовать / преобразовать дальше модель для дальнейшей передачи в другие сервисы?
По моему мнению никакой другой сервис, кроме того сервиса, куда мы первично передали DTO не знает и не должен знать что такое DTO, а это означает, что для дальнейшей передачи DTO уже как модели, нужно создать еще одну фабрику.
Делать 2 фабрики? (Первая - из request в DTO, а потом вторую фабрику из DTO в модель)
Например, хочется использовать DTO, когда мы проксируем запросы пользователя (тонкая модель, меньше свойств, название свойств отличается) в другой микросервис REST API ( у него толстая модель, больше свойств)
Сразу использовать. Часть данных может стать свойствами принимающего объекта, часть данных будет передана в подобъекты получателя и тп. Главное унифицировать, регламинтировать, оптимизировать передачу/получение. Если оно того стоит.
Вопрос пока-что не дающий мне покоя)
В видосе показан пример DTO только с одной структурой данных, допустим, с тем же продуктом. У продукта мы знаем список полей. Ну и допустим, мы можем забубенить их самым примитивным способом как публичные в классе и передавать.
А что делать, когда таких структур данных больше? Не только продукт, а еще и, допустим, комментарий, билет на поезд, заявка с формы обратной связи, и так далее.
- Под каждую структуру делать свой объект DTO, тем самым их размножая под каждую сущность?
- Или обойтись одним объектом, но которому можно динамически задавать поля? Но если это будет один объект с динамическими полями, как тогда убедиться, что в бизнес логику ушла именно нужная структура?
Шо делать :D
Сделать эту структуру в олном классе. Динамические поля точно не надо - лишаемся контроля. Свойства являющиеся доугими dto формально считаются лишним усложнением.
Спасибо! Дмитрий, скажите, а репозитории, описанные в курсе по Laravel, и сервисный слой, это одно и то же (т.к. в некоторых проектах сервисы выполняют и функции работы с БД) или их можно использовать одновременно в контроллерах?
Дмитрий! Очень нравятся твои видео про шаблоны проектирования, спасибо за то что они есть, я понял некоторые вещи благодаря тебе) Ты проделал большую и ценную работу, обязательно поддержу тебя рублём) Есть два вопроса:
1) Porto (apiato) open source, так? Ты не думал поучаствовать в этом проекте? Вроде ты здорово разобрался, используешь его в работе и тд, мог бы внести ценный вклад)
2) К чему акцент и быдло манера в объяснениях? Это местами забавно, но то ли с подачей что-то, то ли слишком часто используется, начало резать ухо.. Складывается впечатление, что это намёк на целевую аудиторию "быдло объяснения для быдлокодеров" :D (это больше обратная связь от одного отдельного человека, чем вопрос)
Вряд ли буду когда нибудь участвовать в OS проектах - либо проекты, либо канал. На то и на другое времени точно не найти.
Автор рассказывает разумные вещи, мне интересно наблюдать.
Но я не согласен с его видением сервисного слоя.
Есть сервисы, а есть сервис провайдеры, зачем нагружать свой di
Не понятно про сервис и сервисный слой. Укажи пожалуйста тайминг к чему это.
На секунду подумал что это java)
А как вы называете объекты-сущности? И используете ли вообще такой подход?
Например, есть DTO - которые собирают набор данных в группу для передачи, есть Model (Laravel) или Entity (Sympfony) - которая описывает данные в БД. Но как быть, когда нам нужно собрать данные в структуру для понятной и удобной работы. Например:
$armor = new Armor();
$armor->setCurrentCapacity(95);
$passenger = new Passenger();
$passenger->setName('Artem');
$passenger->setType(PASSENGER_TYPE::CIVIL);
$passenger->setArmor($armor);
$car = new Car();
$car->addPassenger($passenger);
и допустим эти объекты могут иметь еще с несколько десятков параметров каждый. И допустим ожидается, что планируется еще расширять их в будущем, добавляя новые сущности, например new Weapon(). Добавлять абстракции, когда нам понадобиться несколько видов Armor, несколько видов Passenger и несколько видов Car.
Чем в таком случае являются объекты Car, Passenger, Armor и в другие ? Model или DTO или что-то третье? Думаю это точно не модель описывающая БД. (Хотя теоретически она может и описывать данные из БД). На DTO это похоже, но DTO представляется несколько проще. Поэтому всегда кажется, что это что-то третье. Но что не могу определить.
Так, прочитал описание к видео. Похоже мой вопрос про BLO ). Впервые слышу это понятие. Спасибо за ответ)
$request->validated()
Один собирательный объект. Это ViewModel, а не DTO.
30:20 я это понял, когда еще mixin для scss/sass писал. это жопа когда у тебя больше 3-х параметров ... Я конечно встречал, когда в функцию передавали по 13-20 параметров ... я думал где они руки пропили ...
pandas.read_table(filepath_or_buffer, sep=NoDefault.no_default, delimiter=None, header='infer', names=NoDefault.no_default, index_col=None, usecols=None, squeeze=False, prefix=NoDefault.no_default, mangle_dupe_cols=True, dtype=None, engine=None, converters=None, true_values=None, false_values=None, skipinitialspace=False, skiprows=None, skipfooter=0, nrows=None, na_values=None, keep_default_na=True, na_filter=True, verbose=False, skip_blank_lines=True, parse_dates=False, infer_datetime_format=False, keep_date_col=False, date_parser=None, dayfirst=False, cache_dates=True, iterator=False, chunksize=None, compression='infer', thousands=None, decimal='.', lineterminator=None, quotechar='"', quoting=0, doublequote=True, escapechar=None, comment=None, encoding=None, dialect=None, error_bad_lines=None, warn_bad_lines=None, on_bad_lines=None, encoding_errors='strict', delim_whitespace=False, low_memory=True, memory_map=False, float_precision=None)
Идеально 😁
И наверняка в этой функции 1000+ строк?)
Dto3 вариант, вот тоже начитаешься этих DDDшников, иммутабельность ) начинаешь все это вот так упаковывать, столько лишнего кода, спрашиваешь себя зачем все это? )))
Роберт Мартин отвечает на этот вопрос в книге "Чистая архитектура". Где по сути используя ДТО именует его как примитив.
Дмитрий, а у Вас нет ссылки на репозиторий из данного урока? Хотелось бы посмотреть Ваш код )))
Dto это же структура из с# почти
Исторически из java. C# появился позже.
Почему run вызывается сразу после app() ? Ide не поймёт же что там за тайпхинт. Лучше через DI в конструктор
Для тонкого контроллера не критично - всего одно обращение. Зато -1 параметр в методе.
Можно ли модифицировать данные в DTO, когда он прилетел, к примеру добавить к нему дополнительное поле со значением. Или это уже нарушение концепции?
Когда он прилетел он выполнил свою задачу. Лучше с ним проститься. (так же как и с реквестом в контроллере)
DTO только в котроллерах будет использоваться? Ты хочешь вместо прокидывания параметров передать $request. Я бы не стал делать так потому что контекст может отличаться. Например клиент вводит в форму какие то данные, мы получим обьект $request соответствующий, но вдруг нам стало нужно создать excel документ и контекст совсем другой уже, мы не ждем $request от кого либо и мы просто хотим передать параметры такие же какие могли бы быть в $request. Твой подход способствует дублированию кода.
Ты видео смотрел? Где я предлагаю прокидывать реквест? Или ты только нарезку посмотрел?
@@DmitryAfanasyev на 38 минуте ты сказал "если нет времени может быть можно поставить эту заплатку, может быть это лучше чем передовать 10 параметров в методе". На самом деле не лучше, в первую очередь дублирование искоренять нужно, а потом о параметрах заботится, я это хотел сказать. Параметры вообще такая замарочистая фигня, я лично в работе не парюсь особо за параметры, и не чего страшного не происходит, а вот дублирование очень сильно может испортить жизнь, так как если нужно будет внести правки их придется вносить во все дубли, а ведь можно забыть это сделать и тогда будут косяки которые всплывут не сразу.
@@davidlakazov9156 "Ты хочешь вместо прокидывания параметров передать $request"
Нет, я этого не говорил и не хочу и не советую. Посмотрел 38ю минуту - нет там таких советов. Ты выдумал некую проблему и списал её на меня..... Либо посмотри внимательнее, походу ты что-то не так понял.
Вопрос не по данному видео. На что можно заменить 302 код ответа? Не аякс. Ну например после создания - 201 код можно, а при обновлении, удалении? А то 302 код кэшируется, вот уже 3й раз с ним попадаюсь. то браузер пропускает запрос, а идет далее. Или в Телескоп в Сессии есть success сообщение, но блейд якобы его не видит. Обновляю страницу и еще раз добавляю запись - сообщение с success начинает видеть
Если ты спрашиваешь какие коды используются, то для обновления - 200,204 , а для удаления 200.
@@chincharovpc4120 ну для обновления 200 не шло - ругалось, что 200 не для редиректа. Короче оставил по умолчанию, там для тестового задания по быстрому склепал, без аякса, только удаление на аякс, чтоб в списке не тулить формы
ну ты индеец))
😂
DTO норм тема. Странно что в видео не затронули пакет от спати.
Да вроде его и затронул. Вроде как он и был в Апиато когда-то. Успешно ампутировали этот нарост.
@@DmitryAfanasyev та вроде не было его в апиато. По крайнее мере вы описывали некий пакет pdo в апиато, и охарактеризовали его как нечто адски страшное. У спати пакет прост как гречка, там даже документация на него вмещается на одной странице А4)))
Возник вопрос тока не ругай меня я в этом ещё новичок.
Считается если ли нарушением если DTO наследуется от другого класса?.
Например создал класс BaseDTO там я описал несколько магических методов которые могут повторятся такие как получение данных в разных форматов toArray, создание данных из реквеста моделей и тд и уже ProductDTO extends BaseDTO по сути закон многократного использования сохранятся
Если в базовый класс вынесены методы представления собственных данных, то норм. Дто содеожащий свойство которое тоже дто - это уже не норм. Забыл об этом упомянуть.
Лучше кинь это в трейт
На самом деле имхо лучше дольше проговорить и упомянуть побольше ньюансов. Тем более чтоб не тратить труд и время на перезапись ролика.
Лучше делать так как самому интересно. Ибо как ни старайся придерживаться той или иной концепции - всегда будут не довольные. По этому надо делать "вкайф".
15:23 - может SRP а не SPR ?)
Да, я постоянно это путаю 🙈
@@DmitryAfanasyev ну эт мелочи....а вот видосики О-О-ОЧЕНЬ информативные и содержательные. Если бы можно было как в тик-токе ставить 100500 лайков...)
🙏
Хм, а куда мой коммент пропал....
Либо в спам фильтр либо недолетел если был отправлен с телефона. Врят ли удален, так как если удаляется, то обычно с баном.
@@DmitryAfanasyev я писал, что единственное как можно связать ДТО с анти-паттерном, это анти-паттерн data class. Но сам дядя Боб писал, что есть исключения и data-class не всегда анти-паттерн (Refactoring, 83 стр.)
It is funny. Lol
ДТО зашквар, а вот реквест норм