Статьи javatalks

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

06 дек 2016 18:21
izon Сообщения: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-му. Кто что думает по этому поводу?

06 дек 2016 21:11
wind Сообщения:189	зачем вообще это нужно? класс сущности и есть dto

06 дек 2016 22:41
izon Сообщения:577	wind: зачем вообще это нужно? класс сущности и есть dto Вот даже и не знаю что ответить. Сущности они ведь разные бывают. Ну вот например есть сущность "Накладная" public class Накладная { private String номер; private LocalDate дата; private Организация отправитель; private Организация получатель; private Список<Товар> товары ... // сеттеры геттеры } в нее дважды входит сущность Организация public class Организация { private String краткоеНаименование; private String полноеНаименование; private ФормаСобственности форма собственности; private Список<Телефон> телефоны ... // сеттеры геттеры } в сущность организация входит сущность ФормаСобственности и список сущностей Телефон и так далее и тому подобное, и это еще без списка товаров. И вот, что бы отобразить на клиенте список накладных вида номер-дата-оправитель-получатель, вы мне предлагаете всю эту кучу объектов тащить на клиента? Надеюсь понятно объяснил.

06 дек 2016 22:52
Староверъ Сообщения:10008	Более ООПшный вариант - поместить эти методы в сами Entity или DTO: Dto dto = new Dto(entity); Entity entity = dto.toEntity(); Courses: Java Beginner, Java Professional \| Downsides of anemic model

06 дек 2016 23:38
izon Сообщения:577	Староверъ: Более ООПшный вариант - поместить эти методы в сами Entity или DTO То же интересный вариант, спасибо. Но мне не нравится. Я, скажем так, сторонник анемичной модели, а здесь так вообще модель по сути в фабрику превращается.

06 дек 2016 23:54
Староверъ Сообщения:10008	А еще сторонник инициализировать целый сервис или контроллер чтоб написать маленький модульный тест? :) Courses: Java Beginner, Java Professional \| Downsides of anemic model

07 дек 2016 00:09
izon Сообщения:577	Староверъ: А еще сторонник инициализировать целый сервис или контроллер чтоб написать маленький модульный тест? Вот не понял я вопроса. :( Наверное спать пора.

07 дек 2016 01:38
wind Сообщения:189	izon: Сущности они ведь разные бывают. Иииии? Легче написать несколько фабрик/билдеров или навесить пару аннотаций на те же entity, и их же сериализовать в json?

07 дек 2016 08:41
Староверъ Сообщения:10008	wind: Иииии? Легче написать несколько фабрик/билдеров или навесить пару аннотаций на те же entity, и их же сериализовать в json? На первых порах это, конечно, прокатывает. Но через некоторое время класс весь начинает пестрить аннотациями @Transient, @JsonIgnore, @JsonView. Твоя доменная модель и твой API - это совсем разные вещи и меняться они должны независимо. Courses: Java Beginner, Java Professional \| Downsides of anemic model

07 дек 2016 10:14
izon Сообщения:577	Аннотации здесь вообще не очень подходят. API может иметь несколько вариантов, например "внутренним" пользователям отдаем данное поле, а "внешним" нет. Методы toDTO, fromDTO мне видятся более простым решением. К тому же самым быстрым и легко тестируемым.

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

07 дек 2016 16:50
izon Сообщения:577	Agny: Предлагаю еще более ООПшный вариант: Я правильно понял, что в конце вашего предложения должен стоять такой :) смайлик?

07 дек 2016 17:09
Agny Сообщения:101	Конечно. Ведь паттерны а-ля "фабрика фабрик" призваны вызывать счастливые улыбки разработчиков

07 дек 2016 17:27
izon Сообщения:577	Agny: Конечно. Фух, отлегло. Я с первого прочтения за правду принял, но потом перечитал еще раз и решил уточнить :) Так, на всякий случай, а то знаете-ли всякое бывает :)

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

Модераторы:wedens
Сейчас эту тему просматривают:Нет