Я на 100% заявляю что они плохие (на 85% )) . Но если есть возможность написать норм объект а не DTO - тогда лучше не юзать DTO. Просто пишут в нете что DTO это анти паттерн. Решил узнать.

а антипаттерн это когда у тебя не DTO а анемичная модель

Я на 100% заявляю что они плохие (на 85% )) . Но если есть возможность написать норм объект а не DTO - тогда лучше не юзать DTO. Просто пишут в нете что DTO это анти паттерн. Решил узнать.

Антираттерн он потому, что не является "полноценным обьектом".

но ведь это уже про другое

как это не является?

почему?

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

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

Микросервисы это независимые юниты

(программы)

Антираттерн он потому, что не является "полноценным обьектом".

Да ни разу оно не антипаттерн, это просто структура данных без поведения. Имутабельная структура, сообщение. Ей не нужно поведение. Потому она не подпадает под определение анемичной модели

И ты валидируешь не DTO в таком случае, а просто данные, которые передаются в сети

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

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

Микросервисы это независимые юниты

То есть ты считаешь, что принципилаьная разница между двумя независимо запущенными сервисами на разных серверах и двумя Bounded Context работающий в рамках одного приложения?

Да

Я с точки зрения архитектуры рахницы не вижу

как это не является?

У "объекта" в ООП есть состояние и поведение. У DTO поведения нет. Значит это просто структура, а не объект.

Да в первом случае мы кидаем http запрос, а во втором дергаем метод фасада условно говоря

С точки зрения архитектуры редкий кейс, когда у тебя упал только кусок программы. А вот когда упал один из сервисов - другое дело

В том плане, что обычно весь монолит грохается с ошибкой

Да ни разу оно не антипаттерн, это просто структура данных без поведения. Имутабельная структура, сообщение. Ей не нужно поведение. Потому она не подпадает под определение анемичной модели

А почему анемичность убирается имутабельность?

если мы задрачиваемся на лоу каплинг мы должны понимать что наш сервис/модуль/контекст/компонент может иметь много портов для вызова http запрос, вызов внутри программы, сообщение из рэбита и т.д

У "объекта" в ООП есть состояние и поведение. У DTO поведения нет. Значит это просто структура, а не объект.

Как это нет поведения?)

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

ну хз...я за то чтобы относиться к любым входным данным как к black box

А почему анемичность убирается имутабельность?

нарушение SRP насколько я знаю

но это не точно ☝️

ну хз...я за то чтобы относиться к любым входным данным как к black box

и это порождает кучу валидации, которой можно было бы избежать

А почему анемичность убирается имутабельность?

как правило убирается, у тебя может быть анемичная модель которая используется внутри модуля (а не на границе для коммуникации между модулями) которую юзают на чтение только, но в 95% ситуаций в нее еще и пишут. И проблема тут как раз в контроле за инвариантами

В том плане, что обычно весь монолит грохается с ошибкой

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

и это порождает кучу валидации, которой можно было бы избежать

да это верно

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

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

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

в этом вроде даже одна из основных задумок этой архитектуры

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

так и программа твоя может работать, если проблемы в одном модуле

я вообще для себя определил микросервисы не как архитектру ПО

Как это нет поведения?)

Нет методов.

А почему анемичность убирается имутабельность?

с имутабельными структурами есть только проблема связанности по данным. Нам этой связанности нужно стараться избегать, но между модулями если у тебя есть необходимость расшарить данные то у тебя нет особо вариантов. Проблема в том что часто модулям не нужно шарить данные друг с другом - разве что айдишки. И в очень редких случаях надо что-то большое прокидывать. Чаще жирные DTO можно увидеть там где слои и в языках где нет возможности юзать динамические структуры (Java)

а как подход к деплой и управлению командами разработкой

Нет методов.

Наличие методов != поведение

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

У "объекта" в ООП есть состояние и поведение. У DTO поведения нет. Значит это просто структура, а не объект.

да, и это НЕ делает конкретно DTO антипаттерном. Вопрос как оно применяется

Наличие методов != поведение

да, геттеры и сеттеры тоже про анемичную модель обычно

но отсутствие методов явно отсутствие поведения)

Наличие методов != поведение

Геттеры может есть, а реальных методов нет.

Геттеры может есть, а реальных методов нет.

а что такое реальные методы ? Методы изменяющие состояние?

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

не часть а все, просто некоторые фичи не будут работать. Это больше про преимущества децентрализованных систем

да, и это НЕ делает конкретно DTO антипаттерном. Вопрос как оно применяется

Я про то, что название D. T. Object здесь не очень уместно. Называть лучше D. T. Structure.

а что такое реальные методы ? Методы изменяющие состояние?

сеттеры != поведение

Я про то, что название D. T. Object здесь не очень уместно. Называть лучше D. T. Structure.

ну с этим соглашусь

а что такое реальные методы ? Методы изменяющие состояние?

это методы которые выполняют какую-то работу, а не просто с куска памяти получают данные и возвращают. (Мое видение)

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

Геттеры может есть, а реальных методов нет.

все, что изменяет состояние класса - является его поведением. Даже конструктор класса, который задает полям какое-либо значение - поведение. Но всё поведение - это не только изменение состояния

если у тебя есть некая структура данных с которой на запись работают более одной штуки, для того что бы поддерживать консистентность состояния логику проверки прекондишенов/инвариантов должен содержать тот объект, у которого стэйт

все, что изменяет состояние класса - является его поведением. Даже конструктор класса, который задает полям какое-либо значение - поведение. Но всё поведение - это не только изменение состояния

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

Насчёт тучи сказать не могу. Но в среднем я всегда возвращался на jB IDE во всех случаях, кроме js. Flow у них очень плохо поддерживается.

И тс тож(

раньше был такой принцип как Information hiding, сегодня его всецело заменили на low coupling

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

поэтому предпочитаю в DTO избегать сеттеров

так там даже чисто логически они не нужны

вот сервис сделал какую то работу

надо куда то передать ее результаты, сформировали дто и выбросили

куда в этот ворфлоу впихнуть сеттеры я хз

поэтому предпочитаю в DTO избегать сеттеров

DTO имутабельны должны быть вообще. Ну мол чисто теоритически они нужны только для доставки. То есть ты выплюнул структурку из одного модуля и словил в другом. Вопервых запашек будет идти уже от желания запихнуть эту же структурку кому-то другому. Если ты решил отправить ее тому кто ее тебе прислал - то это будет говорить о том что эта логика должна быть в том модуле который изначально DTO сформировал и тогда можно будет от него просто отказаться. И если надо кому-то еще сообщить чего - это будет уже DTO второго модуля, которую мы кому-то отправим. Новый объект (инстанс класса а не как у Кея)

Посоветуйте хорошую статью про анемическую модель.

ну с этим соглашусь

Поэтому DTObject это не Object с точки зрения терминологии, так как полноценным объектом не является. Поэтому он и антиппатерн.

Поэтому DTObject это не Object с точки зрения терминологии, так как полноценным объектом не является. Поэтому он и антиппатерн.

бля

Посоветуйте хорошую статью про анемическую модель.

классика https://www.martinfowler.com/bliki/AnemicDomainModel.html

Поэтому DTObject это не Object с точки зрения терминологии, так как полноценным объектом не является. Поэтому он и антиппатерн.

если что-то антипаттерн -> этому должна быть альтернатива. Альтернативы нет. DTO Не анти паттерн (потому что альтернативы еще хуже и еще более жесткую связанность пораждают)

Поэтому DTObject это не Object с точки зрения терминологии, так как полноценным объектом не является. Поэтому он и антиппатерн.

ты вообще читаешь что выше пишут?)

ERROR: S client not available

Поэтому DTObject это не Object с точки зрения терминологии, так как полноценным объектом не является. Поэтому он и антиппатерн.

по твоей логике любой объект без поведения антипаттерн ?

дык есть поведение у DTO.

нету

нет

дто это просто коробка

переменная

массив на максималках

массив маминой подруги

дык есть поведение у DTO.

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

дык есть поведение у DTO.

расскажи тогда какое поведение у твоих DTO обычно?

нету

но ведь изменяется состояние объекта. Насколько я знаю, сначала у объекта инициализируются пустые поля. Затем в конструкторе происходит операция присваивания

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

но ведь изменяется состояние объекта. Насколько я знаю, сначала у объекта инициализируются пустые поля. Затем в конструкторе происходит операция присваивания

представь что у тебя нет полей до конструктора)

если что-то антипаттерн -> этому должна быть альтернатива. Альтернативы нет. DTO Не анти паттерн (потому что альтернативы еще хуже и еще более жесткую связанность пораждают)

В некоторых языках есть class для объектов и отдельный struct для данных. Все довольны. Альтернатива есть. Путаницы нет. В PHP есть только class и всё фигачат классами. Есть ассоциативные массивы, но это альтернатива так себе.

class SomeDTO { constructor( val userId: string val something: int ) }

массив маминой подруги

? отличное объяснение для пхпшников

? отличное объяснение для пхпшников

ну не только дл пхпшников, а для всех языков где нет структур данных никаких)

представь что у тебя нет полей до конструктора)

Хотя да, я ошибся, признаю

по твоей логике любой объект без поведения антипаттерн ?

Любой объект без поведения – это не объект, а структура. Любой сервис без состояния, который только что-то вычисляет – это функция.

В некоторых языках есть class для объектов и отдельный struct для данных. Все довольны. Альтернатива есть. Путаницы нет. В PHP есть только class и всё фигачат классами. Есть ассоциативные массивы, но это альтернатива так себе.

Структуры передаются по значению, объекты по ссылке. Если у тебя в php появятся классы (именно классы) которые будут с пометкой data и которые будут передаваться по значению (с copy on write каким например) - то можно считать это структурой. Опять же вся путаница в подмене понятий. Объект != инстанс класса в том панимании которое имеет смысл (против старого доброго процедурного программирования)

ну не только дл пхпшников, а для всех языков где нет структур данных никаких)

А есть языки где наоборот, хех)

Любой объект без поведения – это не объект, а структура. Любой сервис без состояния, который только что-то вычисляет – это функция.

я категорически не согласен с твоим утверждением что все что называется объектом (в силу ограничений языка) и используется как структура это анти паттерн. Важно все же как оно используется. Опять же имутабельность позволяет тебе не париться о различиях как объект передается (по значению или по ссылке)

Любой объект без поведения – это не объект, а структура. Любой сервис без состояния, который только что-то вычисляет – это функция.

да я соглассен с этим. Единственное что сервис не функция, а набор функций. Но почему это антипаттернт то? Имхо стрктура входит во множество объект

Любой объект без поведения – это не объект, а структура. Любой сервис без состояния, который только что-то вычисляет – это функция.

функция которая меняет стэйт структуры -> процедура)

а в делфи было все void функции эт процедуры)

если что-то антипаттерн -> этому должна быть альтернатива. Альтернативы нет. DTO Не анти паттерн (потому что альтернативы еще хуже и еще более жесткую связанность пораждают)

Так и EAV является антипаттерном с точки зрения теории реляционных БД только потому, что является костылём, позволяющим хранить в одной колонке разные типы данных. Но с этим все тоже нормально живут.

Так и EAV является антипаттерном с точки зрения теории реляционных БД только потому, что является костылём, позволяющим хранить в одной колонке разные типы данных. Но с этим все тоже нормально живут.

1. EAV не является антипаттерном, просто у этого подхода проблемы с производительностью. 2. есть JSONB

а не, EAV еще антипаттерн с точки зрения нормализации данных и поддержвания консистентности

ладно

но DTO НЕ! антипаттерн.

а если dto юзается на запись, если dto юзается не на границе между модулями - то это не dto

Это к слову основная причина по которой я не люблю когда люди начинают добавлять суффиксы в названия что бы отличать штуки друг от друга, сущности и dto например. Потому что это говорит о том что суть различий люди не понимают, а потому вынуждены себя убеждать что "вот это DTO" только за счет суффикса