тоже хайп начал спадать. народ начал понимать, что это далеко не серебрянная пуля

бля а кто-то когда-то хотя бы говорил про серебрянные пули?)

нету их, не существует

сколько можно надеяться

народ всегда верит!

нету их, не существует

как жить тогда?)

MVC!! ^)

как жить тогда?)

как жил так и живи

MVC!! ^)

ша тебя тоже ссаными тряпки отметелят за такие сравнения)))

MVC!! ^)

какой из?)

для веба уж

я помню эти глубочайшие споры где и как что должно быть по MVC. что откуда можно читать. какие стрелки куда смотрят...

Ну как вам ООП?

ифы не канон

форматирование кода дерьмо и пробел перед точкой

форматирование кода дерьмо и пробел перед точкой

Это ж прикол народ и уборщица которая клеила стикеры вряд ли в кодьстайле шарила

Это ж прикол народ и уборщица которая клеила стикеры вряд ли в кодьстайле шарила

э, нам дали отревьюить код - мы сделали we had one job

э, нам дали отревьюить код - мы сделали we had one job

????

Ну как вам ООП?

а если female, у этого же туалета будет другое направление?

это же вообще минифицированный код (но не углифицированный). Просто у редактора типа "дверь" nowrap установлен в false

В DTO не может быть сетеров верно, вся инициализация должна проходитьчерез конструктор, иначе будет возможность изменить состояние обекта.Верно?

В DTO не может быть сетеров верно, вся инициализация должна проходитьчерез конструктор, иначе будет возможность изменить состояние обекта.Верно?

нет, неизменяемость - это про VO в первую очередь

с другой стороны - понятия не имею, зачем тебе изменять DTO

чтото добавить например в ответ

ну то есть твое dto проходит какие-то этапы?

опять-таки без специфики непонятно

например апи возвращает джесон. я конвертирую и формирую в объект для дальнейших работы.

В DTO не может быть сетеров верно, вся инициализация должна проходитьчерез конструктор, иначе будет возможность изменить состояние обекта.Верно?

ну необходимости менять DTO особо нету

а ну @thatside уже тоже удивился

чтото добавить например в ответ

ну это нормально

я поэтому не очень за то что бы DTO для респонсов через конструктор собирать, либо тогда должна быть сверху какая-то обертка которая будет разруливать мердж данных

например апи возвращает джесон. я конвертирую и формирую в объект для дальнейших работы.

а может ты ответ апи (dto, содержащий жсон) превратишь в другой дто (уже объект)?

а может ты ответ апи (dto, содержащий жсон) превратишь в другой дто (уже объект)?

ну у меня например ситуация такая. Есть довольно жирные ответы для клиента и есть целая куча похожих DTO. И все данные всегда достаются сверху и передаются в конструктор (или фабрику). И меня это сильн напрягает потому что это и неудобно и связанность высокая выходит

ну у тебя да, своеобразная ситуация склеивать ответы влом а когда ты получил данные и передаешь их дальше - не вижу смысла лепить патчинг

ясно спс

ну у тебя да, своеобразная ситуация склеивать ответы влом а когда ты получил данные и передаешь их дальше - не вижу смысла лепить патчинг

ну я по итогу пока эксперементирую со всякими конструкциями вида return compose(oneDto, secondDto)

ну я по итогу пока эксперементирую со всякими конструкциями вида return compose(oneDto, secondDto)

compose тупо мерджит все?

compose тупо мерджит все?

да, но.... сложно

а какие - то сложные сценарии? типа одно поле из дто1, второе из дто2

при этом оба поля есть и там, и там

а symfony options_resolver не пододет?

а какие - то сложные сценарии? типа одно поле из дто1, второе из дто2

compose(filter(dto1), filter(dto2))....

ну короч ты можешь в целом все это сделать но мне пока не нравится)

а symfony options_resolver не пододет?

мм.... нет)))

compose(filter(dto1), filter(dto2))....

а фильтр что делает? и как?)

вообще я хочу от DTO для респонсов избавиться.... в целом необходимость в DTO нужна там, где у тебя есть граница, и с одной стороны DTO объявляется и формируется, а с другой стороны потребляется. В случае составления json мне в целом DTO нужны только что бы данными наполнять некий сборщик, далее все происходит с одной стороны границы

вообще я хочу от DTO для респонсов избавиться.... в целом необходимость в DTO нужна там, где у тебя есть граница, и с одной стороны DTO объявляется и формируется, а с другой стороны потребляется. В случае составления json мне в целом DTO нужны только что бы данными наполнять некий сборщик, далее все происходит с одной стороны границы

а что, если границу по сборщику провести?)

а что, если границу по сборщику провести?)

зачем?

зачем?

эт так, предположение

тебе ведь нужно откуда-то получать данные из сущностей - не ня

тебе нужно что-то, что будет знать, че вообще нужно конкретному ответу

тебе ведь нужно откуда-то получать данные из сущностей - не ня

ну сборщик кого-то на границе просит, а там ему хочешь сущность, хочешь dto

с учетом его композитности

просто DTO этих сильно меньше чем вариантов респонса

подчеркиваю - я не хочу DTO дублирующие структуру респонса

ну да, много тупых объектов не оч интересно ворочать... соответственно, умным у тебя является/будет сборщик а как сборщик разруливает то, какой ответ он должен отдать? (как понимаю - сейчас сборщик/compose тупой и собирает все просто на основе дто, которые ему отдали)

ну да, много тупых объектов не оч интересно ворочать... соответственно, умным у тебя является/будет сборщик а как сборщик разруливает то, какой ответ он должен отдать? (как понимаю - сейчас сборщик/compose тупой и собирает все просто на основе дто, которые ему отдали)

ну клиентский код говорит ему что требуется

а он собирает

у него внутри правила типа

просто это уже очень близко к дто на каждый респонс вместо этого у тебя просто получается, грубо говоря, иф на каждый респонс (внутри сборщика)

ну я по итогу пока эксперементирую со всякими конструкциями вида return compose(oneDto, secondDto)

Лучше merge, а то compose обычно про другое)

Лучше merge, а то compose обычно про другое)

ну ты меня понял)

просто это уже очень близко к дто на каждый респонс вместо этого у тебя просто получается, грубо говоря, иф на каждый респонс (внутри сборщика)

поверь, не близко)

ну ты меня понял)

Эт да

поверь, не близко)

окей, верю, но пока не понимаю)

В DTO не может быть сетеров верно, вся инициализация должна проходитьчерез конструктор, иначе будет возможность изменить состояние обекта.Верно?

нет, ты путаешь dto и имутабельность

хорошо когда dto имутабельно, но это не обязательно

хорошо когда dto имутабельно, но это не обязательно

в целом критерий хорошего DTO - его можно без проблем сериализировать, что бы по сети например передать. То же и про ивенты.

хорошо когда dto имутабельно, но это не обязательно

какой смысл имутабельноти dto? это просто объект который несет данные

какой смысл имутабельноти dto? это просто объект который несет данные

Смысл иммутабельности (и не только dto) в том, чтоб не было такого, что один участок кода данные поменял, а другой участок кода этого "не ожидал" - потом такое дебажить - боль

Смысл иммутабельности (и не только dto) в том, чтоб не было такого, что один участок кода данные поменял, а другой участок кода этого "не ожидал" - потом такое дебажить - боль

применительно именно к dto я это не особо понимаю. что именно ты не ожидал что параметр какой то будет = 2 а не 1му ?

хотя в плане дебага наверное да, с этим проще будет

применительно именно к dto я это не особо понимаю. что именно ты не ожидал что параметр какой то будет = 2 а не 1му ?

Потому что багах часто приходится искать, кто и где это 2 присвоил

... и с какой целью :)

ну а если тебе нужно по каким то правилам изменить данные которые должные прийти конечному потребителю?

один фиг придется создавть дто с измененными данными и прокидывать. и опять к тому же самому возвращаемся

какой смысл имутабельноти dto? это просто объект который несет данные

пока он несет никто нигде ничего не поменяет

кругом враги

один фиг придется создавть дто с измененными данными и прокидывать. и опять к тому же самому возвращаемся

Это уже выбор хай-левел функции, работать с измененными (новыми) данными или с оригиналом

На правах рекламы: https://functionalprogramming.slack.com