Приношу извинения разработчикам с "АСиКью ТикТокера", изо всех сил пытался говорить кратко - не вышло. Сорямба. тиктокеры - го в тикток. Остальным - приятного просмотра! 👍
the best author ever! Спасибо большое за видосик!!! По видосеку увидел, что Махмуд в апиато контроллерах не пробрасывает реквест, а делает деструктуризацию реквеста и передает его как простыми параметрами функций, т.е. по сути это ок, т.к. все остальная логика методов реквеста "купируется" в контроллере и не передается дальше по моделям. А заменить потом примитивы на dto на порядок проще, чем копаться с реквестом в моделя, так что no worries, думаю что дто туда или вернется или появится какая-то моделька. DTO можно юзать как метод борьбы с плохим кодом в процессе рефакта, в частности с "одержимостью примитивами" (Фаулер). Но на этапе проектирования и кодирования я бы конечно избегал юзания dto в пользу полноценных моделек
Привет Дмитрий! Сижу смотрю видео и вспоминаю, как 6 лет назад делал первые шаги в программировании и учил php по вашему курсу с магазином. На данный момент работаю Senior Angular Developer в епаме, сам организовываю уже 3-ти курсы у себя в небольшом городе, и хорошо зарабатываю. Хочу Вам во-первых сказать СПАСИБО!!! Что делитесь такой ценной информацией. И второе: что 6 лет назад что сейчас ваши видео очень полезны!
Дим, спасибо большое за твой контент, очень круто. По поводу бритвы Окамме и того, что когда использовать или не использовать по необходимости, с опытом я пришел к выводу, что единообразие подходов в проекте важнее, ибо когда разработчик видит разные релизации и подходы в одном проекте, это пораждает лишнюю когнитивную нагрузку, поэтому я как тим лид сейчас делаю строго круглое кати квадратное неси, мы выбираем подход единый и используем по всему проекту, выбрали ДТО, просто берем и делаем так всегда, выбрали разделение на команды и запросы, значит делаем так всегда и т.д, насчет сложности, сложность = незнание, поэтому мы устраняем незнание, объясняем и делаем код ревью где все разработчики подтягиваются до нужного уровня понимания, сложность уходит
Ахаха, Дмитрий, видео огонь! Четко, понятно и с юмором, как всегда! Спасибо, что озвучил свое мнение про проброс реквестов в Апиато. А то я аж присел от неожиданности, когда увидел в 10й версии пропихивание реквеста в Action)).
Здравствуйте! Смотрел ранее ваши видео про Ларавель, за них отдельное спасибо! В начале месяца нашёл свою первую работу в должности разработчика. Без Ларавеля, но на чистом 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. Не стоит их путать. В конструкторе периода дат мы можем добавить какие-нибудь проверки и выкинуть исключение + повторно использовать и прокидывать в разные методы.
38:56 вот не соглашусь с передачей модельки вместо создания её ДТОшной копии. У модели поведение, метод, в который её передают, возьмёт и изменит её состояние через её публичные методы (может, сегодня их нет, завтра добавят, послезавтра забудут, что они значат, а ещё через 3 дня новый девелопер, работающий с подсистемой, куда передали эту модель, возьмёт и дёргнет эти методы, а почему бы и нет, ему же её передали с методами, значит можно дёргать, он формально прав). DTO пресекает эту проблему на корню
Вот я головой понимаю, что почитать про dto можно на хабре причем ты потратишь 5 минут. Я трачу 41 минуту. Все же классно , Дмитрий, ты рассказываешь :)
Дмитрий, спасибо за интересное видео, с удовольствием посмотрел) Отдельное спасибо за разбор либы. Это интересно. Можете рассказать, а в чем отличие DTO от ValueObject?
ох ёёпт! кто проявился... пол года не было, наверно... работы только наверное много.. пропадаешь так.. я так хотел по твоим видосам освоить пхп и ооп и ларавель и всё остальное... но проклятый джаваскрипт пришОл и всё испортил :-) хотя шаблоны проектирования можно просмотреть наверное.. вот нагрузка джуновская спадёт и займусь. А ты пили видосы хоть иногда! мол жив здоров.. :-) удачи!
Не хочу быть душнилой, но 1) не SPR(эспэр), а SRP (эсэрпи). 2) static function createFromArray(...) - статическая фабрика 3) никогда не слышал, чтобы статические фабрики нарушали SRP. Сказать, что статическая фабрика нарушает SRP - то же самое, что сказать, что SRP нарушается перегрузкой конструктора в той же Java. 4) классы-фабкири DTO объектов называются DtoAssembler-ами и служат чем-то вроде внешнего конструктора для DTO, у которого все свойства публичны 5) инкапсуляция - не сокрытие данных, а процесс соблюдения инвариантов А в целом рад, что такие ролики выходят в русском сегменте Сети. Ты первый, на кого я наткнулся, кто сказал о том, что конструкторы и приватные доступы к свойствам зачастую лишние. Это круто
Спасибо! Дмитрий, скажите, а репозитории, описанные в курсе по Laravel, и сервисный слой, это одно и то же (т.к. в некоторых проектах сервисы выполняют и функции работы с БД) или их можно использовать одновременно в контроллерах?
Дмитрий! Очень нравятся твои видео про шаблоны проектирования, спасибо за то что они есть, я понял некоторые вещи благодаря тебе) Ты проделал большую и ценную работу, обязательно поддержу тебя рублём) Есть два вопроса: 1) Porto (apiato) open source, так? Ты не думал поучаствовать в этом проекте? Вроде ты здорово разобрался, используешь его в работе и тд, мог бы внести ценный вклад) 2) К чему акцент и быдло манера в объяснениях? Это местами забавно, но то ли с подачей что-то, то ли слишком часто используется, начало резать ухо.. Складывается впечатление, что это намёк на целевую аудиторию "быдло объяснения для быдлокодеров" :D (это больше обратная связь от одного отдельного человека, чем вопрос)
Dto4 я описываю $fields = ["id", "name", "addres".... ]; поля в массиве, и потом просто по нему пробегают, тоже самое что и у полей класса брать, но более явно :)
А как вы называете объекты-сущности? И используете ли вообще такой подход? Например, есть 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 представляется несколько проще. Поэтому всегда кажется, что это что-то третье. Но что не могу определить.
Вопрос не по данному видео. На что можно заменить 302 код ответа? Не аякс. Ну например после создания - 201 код можно, а при обновлении, удалении? А то 302 код кэшируется, вот уже 3й раз с ним попадаюсь. то браузер пропускает запрос, а идет далее. Или в Телескоп в Сессии есть success сообщение, но блейд якобы его не видит. Обновляю страницу и еще раз добавляю запись - сообщение с success начинает видеть
@@chincharovpc4120 ну для обновления 200 не шло - ругалось, что 200 не для редиректа. Короче оставил по умолчанию, там для тестового задания по быстрому склепал, без аякса, только удаление на аякс, чтоб в списке не тулить формы
... здесь мы нарушаем принцип единственной ответственности ... ))) да блин, ну давайте уже примем за факт что этот принцип все всегда нарушают в той или иной степени. мир праху SRP )
Не вижу сложностей в соблюдении SRP. Зато видел много сложностей в поддержке кода когда его не соблюдали. Нарушать его можно только при полном понимании последствий.
@@DmitryAfanasyev да согласен в целом, просто с срп растет не файл или класс, а количество файлов. В которых классы делающие чтото одно, как просто так и сложно можно сделать и так и так. Надо делать просто
Как потом DTO использовать / преобразовать дальше модель для дальнейшей передачи в другие сервисы? По моему мнению никакой другой сервис, кроме того сервиса, куда мы первично передали DTO не знает и не должен знать что такое DTO, а это означает, что для дальнейшей передачи DTO уже как модели, нужно создать еще одну фабрику. Делать 2 фабрики? (Первая - из request в DTO, а потом вторую фабрику из DTO в модель) Например, хочется использовать DTO, когда мы проксируем запросы пользователя (тонкая модель, меньше свойств, название свойств отличается) в другой микросервис REST API ( у него толстая модель, больше свойств)
Сразу использовать. Часть данных может стать свойствами принимающего объекта, часть данных будет передана в подобъекты получателя и тп. Главное унифицировать, регламинтировать, оптимизировать передачу/получение. Если оно того стоит.
Автор рассказывает разумные вещи, мне интересно наблюдать. Но я не согласен с его видением сервисного слоя. Есть сервисы, а есть сервис провайдеры, зачем нагружать свой di
Возник вопрос тока не ругай меня я в этом ещё новичок. Считается если ли нарушением если DTO наследуется от другого класса?. Например создал класс BaseDTO там я описал несколько магических методов которые могут повторятся такие как получение данных в разных форматов toArray, создание данных из реквеста моделей и тд и уже ProductDTO extends BaseDTO по сути закон многократного использования сохранятся
Если в базовый класс вынесены методы представления собственных данных, то норм. Дто содеожащий свойство которое тоже дто - это уже не норм. Забыл об этом упомянуть.
Вопрос пока-что не дающий мне покоя) В видосе показан пример DTO только с одной структурой данных, допустим, с тем же продуктом. У продукта мы знаем список полей. Ну и допустим, мы можем забубенить их самым примитивным способом как публичные в классе и передавать. А что делать, когда таких структур данных больше? Не только продукт, а еще и, допустим, комментарий, билет на поезд, заявка с формы обратной связи, и так далее. - Под каждую структуру делать свой объект DTO, тем самым их размножая под каждую сущность? - Или обойтись одним объектом, но которому можно динамически задавать поля? Но если это будет один объект с динамическими полями, как тогда убедиться, что в бизнес логику ушла именно нужная структура? Шо делать :D
Сделать эту структуру в олном классе. Динамические поля точно не надо - лишаемся контроля. Свойства являющиеся доугими dto формально считаются лишним усложнением.
DTO только в котроллерах будет использоваться? Ты хочешь вместо прокидывания параметров передать $request. Я бы не стал делать так потому что контекст может отличаться. Например клиент вводит в форму какие то данные, мы получим обьект $request соответствующий, но вдруг нам стало нужно создать excel документ и контекст совсем другой уже, мы не ждем $request от кого либо и мы просто хотим передать параметры такие же какие могли бы быть в $request. Твой подход способствует дублированию кода.
@@DmitryAfanasyev на 38 минуте ты сказал "если нет времени может быть можно поставить эту заплатку, может быть это лучше чем передовать 10 параметров в методе". На самом деле не лучше, в первую очередь дублирование искоренять нужно, а потом о параметрах заботится, я это хотел сказать. Параметры вообще такая замарочистая фигня, я лично в работе не парюсь особо за параметры, и не чего страшного не происходит, а вот дублирование очень сильно может испортить жизнь, так как если нужно будет внести правки их придется вносить во все дубли, а ведь можно забыть это сделать и тогда будут косяки которые всплывут не сразу.
@@davidlakazov9156 "Ты хочешь вместо прокидывания параметров передать $request" Нет, я этого не говорил и не хочу и не советую. Посмотрел 38ю минуту - нет там таких советов. Ты выдумал некую проблему и списал её на меня..... Либо посмотри внимательнее, походу ты что-то не так понял.
Dto3 вариант, вот тоже начитаешься этих DDDшников, иммутабельность ) начинаешь все это вот так упаковывать, столько лишнего кода, спрашиваешь себя зачем все это? )))
30:20 я это понял, когда еще mixin для scss/sass писал. это жопа когда у тебя больше 3-х параметров ... Я конечно встречал, когда в функцию передавали по 13-20 параметров ... я думал где они руки пропили ...
@@DmitryAfanasyev та вроде не было его в апиато. По крайнее мере вы описывали некий пакет pdo в апиато, и охарактеризовали его как нечто адски страшное. У спати пакет прост как гречка, там даже документация на него вмещается на одной странице А4)))
Лучше делать так как самому интересно. Ибо как ни старайся придерживаться той или иной концепции - всегда будут не довольные. По этому надо делать "вкайф".
@@DmitryAfanasyev я писал, что единственное как можно связать ДТО с анти-паттерном, это анти-паттерн data class. Но сам дядя Боб писал, что есть исключения и data-class не всегда анти-паттерн (Refactoring, 83 стр.)
