Size: a a a

Spring Framework and more

2019 July 01

Д

Дмитрий in Spring Framework and more
Alexander Yakovlev
Есть холиварный вопрос, по поводу если у нас Entity совпадает с DTO, то стоит ли вообще делать DTO, если мы можем все на уровне Jackson-а разруливать.

Просто если мы вводим понятие DTO, и наш сервис будет как слой возвращать только его, то при обращении из сервиса сервис нужно конвертировать постоянно (Entity<->DTO) и использовать репозитории + нам придется писать какую нибудь дублирующуюся логику (например для проверки сущтвования сущности).

Имеет смысл выности преобразование на уровень контоллеров, чтоб избавиться от этого или вообще писать DTO? Хотя есть боязнь, что потечь может...
стоит следовать принципам SOILD -> разделять объект предназнченный для хранения в БД и объект для внешних клиентов
источник

u

umka.me in Spring Framework and more
Alexander Yakovlev
Есть холиварный вопрос, по поводу если у нас Entity совпадает с DTO, то стоит ли вообще делать DTO, если мы можем все на уровне Jackson-а разруливать.

Просто если мы вводим понятие DTO, и наш сервис будет как слой возвращать только его, то при обращении из сервиса сервис нужно конвертировать постоянно (Entity<->DTO) и использовать репозитории + нам придется писать какую нибудь дублирующуюся логику (например для проверки сущтвования сущности).

Имеет смысл выности преобразование на уровень контоллеров, чтоб избавиться от этого или вообще писать DTO? Хотя есть боязнь, что потечь может...
Соглашусь с предыдущим оратором, DTO это нечто что выходит из сервиса в контроллер, а дальше на клиент. Но работают сервисы и все что выше только с entity
источник

AY

Alexander Yakovlev in Spring Framework and more
Дмитрий
стоит следовать принципам SOILD -> разделять объект предназнченный для хранения в БД и объект для внешних клиентов
Просто тут вопрос в том, например у нас пришла сущность DTO с двувумя Id  
class A {
 Long id;
}

class B {
 Long id;
}
class ABDTO {
 Long aId;
 Long bId;
}

И мы к примеру обращаемся в сервис ABService

Так бы можно было бы просто вызвать из сервиса сервис, т.е. aService.getById(...) - и там уже есть обработка данной ошибки если сущность не найдена и не надо писать тут какие то дополнительные проверки.
источник

u

umka.me in Spring Framework and more
Как она у вас пришла с 2мя  Id?
источник

u

umka.me in Spring Framework and more
У вас что-то не так - 2 разных Entity(как я понимаю - A и B) обрабатываются одним сервисом?
источник

Д

Дмитрий in Spring Framework and more
Alexander Yakovlev
Просто тут вопрос в том, например у нас пришла сущность DTO с двувумя Id  
class A {
 Long id;
}

class B {
 Long id;
}
class ABDTO {
 Long aId;
 Long bId;
}

И мы к примеру обращаемся в сервис ABService

Так бы можно было бы просто вызвать из сервиса сервис, т.е. aService.getById(...) - и там уже есть обработка данной ошибки если сущность не найдена и не надо писать тут какие то дополнительные проверки.
честно я ничего не понял)
источник

AY

Alexander Yakovlev in Spring Framework and more
Ну смотри, есть сервисы в которых уже построен CRUD
источник

Д

Дмитрий in Spring Framework and more
да всё, после того как вы добавили bId стало яснее)
источник

Д

Дмитрий in Spring Framework and more
ну у вас будет сервис, который в себе содержит 2 других сервиса и юзает их, не в контроллере же этим заниматься
источник

AY

Alexander Yakovlev in Spring Framework and more
Дмитрий
ну у вас будет сервис, который в себе содержит 2 других сервиса и юзает их, не в контроллере же этим заниматься
Это понятно, только если сервис возвращает DTO то там еще преобразований куча
источник

Д

Дмитрий in Spring Framework and more
Alexander Yakovlev
Это понятно, только если сервис возвращает DTO то там еще преобразований куча
преобразований каких и где
источник

AY

Alexander Yakovlev in Spring Framework and more
Если мы предполагаем что все сервисы должны возвращать DTO
источник

Д

Дмитрий in Spring Framework and more
ну я пока проблемы не понимаю, возвращается вам ДТО в ваш новый сервис, делайте там с ним всё что вам нужно...
источник

AY

Alexander Yakovlev in Spring Framework and more
И потом нужно сохранить, т.е. обратно в Entity и после что то вернуть, обратно в DTO 🤔
источник

PB

Pavel Bukhmatov in Spring Framework and more
Alexander Yakovlev
Есть холиварный вопрос, по поводу если у нас Entity совпадает с DTO, то стоит ли вообще делать DTO, если мы можем все на уровне Jackson-а разруливать.

Просто если мы вводим понятие DTO, и наш сервис будет как слой возвращать только его, то при обращении из сервиса сервис нужно конвертировать постоянно (Entity<->DTO) и использовать репозитории + нам придется писать какую нибудь дублирующуюся логику (например для проверки сущтвования сущности).

Имеет смысл выности преобразование на уровень контоллеров, чтоб избавиться от этого или вообще писать DTO? Хотя есть боязнь, что потечь может...
А есть возможность генерировать dto + "entity" одновременно через jooq, например?

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

Д

Дмитрий in Spring Framework and more
ну во первых, вам никто не запрещает из сервиса возвращать entity , во творых никто не запрещает заимплементить логику прямо в сервисе А/B если это возможно, сервис это как правило не просто прослойка между контроллером и репозиторием/дао
источник

AY

Alexander Yakovlev in Spring Framework and more
Дмитрий
ну во первых, вам никто не запрещает из сервиса возвращать entity , во творых никто не запрещает заимплементить логику прямо в сервисе А/B если это возможно, сервис это как правило не просто прослойка между контроллером и репозиторием/дао
Просто хотелось бы как то изолировать тогда возрат DTO и общение с контроллерами, но и также сделать нормальную работу с Entity на уровне сервисов
источник

Д

Дмитрий in Spring Framework and more
Alexander Yakovlev
Просто хотелось бы как то изолировать тогда возрат DTO и общение с контроллерами, но и также сделать нормальную работу с Entity на уровне сервисов
методы возвращающие Entity всегда можно сделать package private , если у вас там не 100500 сервисов и все 1 в одном пакете
источник

Д

Дмитрий in Spring Framework and more
ну или как минимум вынести в отдельный пакет, раз уж А и Б тесно связанны, что впринципе напрашивается само собой
источник

AY

Alexander Yakovlev in Spring Framework and more
Т.е. инжектить в сервисе сервисы придется не через интерфейсы, а напрямую - как вариант конечно, или можно интерфейсами скрывать для контроллера, который отдельно только DTO возвращает, а для сервисов Entity🤔
источник