JB
Да, тоже перечитал, в итоге нашел утверждение (не факт что точно верное), что дто - подвид поджо)
Size: a a a
2021 June 21
PL
PL
поджо - просто класс
PL
дто - класс который передается наружу
PL
и не важно как ты его назовешь
PL
dto, pojo, request/response, если у тебя объявлен конкретный тип в сваггере, и этот тип тебе передает фронт (или другой мс) /ты передаешь фронту (или другому мс) - это и есть дто
JB
+ ну по крайней мере использую "дто", для типизации данных, просачиваемых наружу)
PL
другой вопрос что этот дто может использоваться как энтити, то есть объект как лежит в базе, так его могут и передавать наружу, как пример
PL
в таком случае этот класс будет и энтити и дто
PL
даже если у него на конце не будет постфиксов entity/dto
DE
PL
каких вызовов? куда? мне интересно узнать как ты понимаешь зачем это надо, а не ссылки из интернета
JB
++
Только вот что я понял, дто то не всегда нужен при общении с другими/сторонними сервисами в рамках неста, например в случае запроса, который на внешний сервис отправляешь с бэка, и ожидаешь ответ, то почему бы не прописать интерфейс, да и покончили с этим
Только вот что я понял, дто то не всегда нужен при общении с другими/сторонними сервисами в рамках неста, например в случае запроса, который на внешний сервис отправляешь с бэка, и ожидаешь ответ, то почему бы не прописать интерфейс, да и покончили с этим
JB
Да, только понял, что редко, когда дто/ентити можно объединять, да и для единой стилистики во всем проекте, разделять дто/ентити. Так можно в дто конструкторе определить правила маппинге энтити)
DE
Я же сказал что считаю их применение лишним. Возможно потом они и пригодятся, но почему не описать все эти DTO в одном вложенном массиве, мне не понятно
PL
ты так и не ответил зачем это надо кроме как то что оно тебе мешает самим фактом что существует
JB
Мб чтоб не генерить годмод объект/массив
PL
это вкусовщина каждого
DE
Это мой вопрос зачем?
PL
кто-то любит хранить мухи отдельно, котлеты отдельно