javatalks.ru
Статьи javatalks

Преобразование Entity <-> DTO

 
anchor
06 дек 2016 20:21  
 
Сообщения:577
Есть backend на Spring (REST) который отдает наружу DTO в JSON формате, само приложение разделено
на слои: контроллеры (взаимодействие с внешним миром), сервисы (вся бизнес-логика), dao (работа с БД).
Не дает покоя вопрос где (и как) лучше осуществлять преобразование Entity->DTO и обратно.
Мне видится несколько вариантов:
1. методы toDTO, fromDTO в контроллере
+ DTO используются только в контроллерах, где им в общем-то и место
- у контроллеров появляются ненужные зависимости
- нарушается принцип единой ответственности
2. методы toDTO, fromDTO в сервисе
+ если рассматривать такое преобразование как часть бизнес-логики, то это правильное место
- а если нет, то опять же нарушается принцип единой ответственности
3. отдельные helpers бины
+ может использоваться независимо в разных частях приложения
- в зависимости от реализации может потребовать создания "лишних" методов в сервисном слое
или управления транзакциями
4. всякие "магические" штуки вроде Converter, Formatter, Dozer, ModelMapper и т.п.

Сейчас использую вариант 2, но склоняюсь к 3-му.

Кто что думает по этому поводу?
anchor
06 дек 2016 23:11  
 
Сообщения:189
зачем вообще это нужно? класс сущности и есть dto
anchor
07 дек 2016 00:41  
 
Сообщения:577
wind:
зачем вообще это нужно? класс сущности и есть dto

Вот даже и не знаю что ответить. Сущности они ведь разные бывают.

Ну вот например есть сущность "Накладная"
public class Накладная {
    private String номер;
    private LocalDate дата;
    private Организация отправитель;
    private Организация получатель;
    private Список<Товар> товары
    ...
    // сеттеры геттеры
}

в нее дважды входит сущность Организация
public class Организация {
    private String краткоеНаименование;
    private String полноеНаименование;
    private ФормаСобственности форма собственности;
    private Список<Телефон> телефоны
    ...
    // сеттеры геттеры
}

в сущность организация входит сущность ФормаСобственности и список сущностей Телефон и так далее и тому подобное, и это еще без списка товаров.
И вот, что бы отобразить на клиенте список накладных вида номер-дата-оправитель-получатель, вы мне предлагаете всю эту кучу объектов тащить на клиента?
Надеюсь понятно объяснил.
anchor
07 дек 2016 00:52  
 
Сообщения:10008
Более ООПшный вариант - поместить эти методы в сами Entity или DTO:
Dto dto = new Dto(entity);
Entity entity = dto.toEntity();
Courses: Java Beginner, Java Professional | Downsides of anemic model
anchor
07 дек 2016 01:38  
 
Сообщения:577
Староверъ:
Более ООПшный вариант - поместить эти методы в сами Entity или DTO

То же интересный вариант, спасибо.
Но мне не нравится. Я, скажем так, сторонник анемичной модели, а здесь так вообще модель по сути в фабрику превращается.
anchor
07 дек 2016 01:54  
 
Сообщения:10008
А еще сторонник инициализировать целый сервис или контроллер чтоб написать маленький модульный тест? :)
Courses: Java Beginner, Java Professional | Downsides of anemic model
anchor
07 дек 2016 02:09  
 
Сообщения:577
Староверъ:
А еще сторонник инициализировать целый сервис или контроллер чтоб написать маленький модульный тест?

Вот не понял я вопроса. :(
Наверное спать пора.
anchor
07 дек 2016 03:38  
 
Сообщения:189
izon:
Сущности они ведь разные бывают.

Иииии? Легче написать несколько фабрик/билдеров или навесить пару аннотаций на те же entity, и их же сериализовать в json?
anchor
07 дек 2016 10:41  
 
Сообщения:10008
wind:
Иииии? Легче написать несколько фабрик/билдеров или навесить пару аннотаций на те же entity, и их же сериализовать в json?
На первых порах это, конечно, прокатывает. Но через некоторое время класс весь начинает пестрить аннотациями @Transient, @JsonIgnore, @JsonView. Твоя доменная модель и твой API - это совсем разные вещи и меняться они должны независимо.
Courses: Java Beginner, Java Professional | Downsides of anemic model
anchor
07 дек 2016 12:14  
 
Сообщения:577
Аннотации здесь вообще не очень подходят. API может иметь несколько вариантов, например "внутренним" пользователям отдаем данное поле, а "внешним" нет.
Методы toDTO, fromDTO мне видятся более простым решением. К тому же самым быстрым и легко тестируемым.
anchor
07 дек 2016 18:26  
 
Сообщения:101
Староверъ:
Более ООПшный вариант - поместить эти методы в сами Entity или DTO:

Предлагаю еще более ООПшный вариант: вводим соответствующие интерфейсы (на "to" и на "from"), добавляем интерфейс-агрегатор, имплементим это добро где надо и наслаждаемся.
/offtop я ошибаюсь, или в давнишней версии форума были смайлики, а в этой нет?
anchor
07 дек 2016 18:50  
 
Сообщения:577
Agny:
Предлагаю еще более ООПшный вариант:

Я правильно понял, что в конце вашего предложения должен стоять такой :) смайлик?
anchor
07 дек 2016 19:09  
 
Сообщения:101
Конечно. Ведь паттерны а-ля "фабрика фабрик" призваны вызывать счастливые улыбки разработчиков
anchor
07 дек 2016 19:27  
 
Сообщения:577
Agny:
Конечно.

Фух, отлегло.
Я с первого прочтения за правду принял, но потом перечитал еще раз и решил уточнить :) Так, на всякий случай, а то знаете-ли всякое бывает :)
anchor
07 дек 2016 19:47  
 
Сообщения:101
Ну, на самом деле, у такого подхода есть свои плюсы:
- вводится набор свойств, непривязанных к конкретной доменной модели и вообще к чему-либо;
- над этими свойствами можно накрутить какую угодно алгебру поведения/обработку: если вдруг появляется необходимость выгрузить dto и от списка организаций и от накладных, Вы можете и те и другие рассматривать как набор выше объявленных свойств;
- это просто прикольно :)
Другое дело, конечно, что в java это очень вербозно получается. Да и не всегда такой уровень абстракции нужен, KISS никто не отменял.
 
Модераторы:wedens
Сейчас эту тему просматривают:Нет