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

 
 
 
Сообщения:577
Agny:
KISS никто не отменял.
Мне иногда кажется что это принцип не просто отменили, а запретили.
Изменен:07 дек 2016 15:22
 
 
Сообщения:897
А чем не устраивает MVC? В контроллер вставляются зависимости от представления и модели. За трансформацию модели в ДТО отвечает именно представление, которое при необходимости можно заменить.
 
 
Сообщения:189
Староверъ:
На первых порах это, конечно, прокатывает. Но через некоторое время класс весь начинает пестрить аннотациями @Transient, @JsonIgnore, @JsonView. Твоя доменная модель и твой API - это совсем разные вещи и меняться они должны независимо.

Для этого и эксплуатируются ООП-ориентированные языки, по мере накопления серьезных различий сущности и представления, модель разрастается. А что за беда такая "пестрит аннотациями", и кто от этого помер - лично я не в курсе. И модель данных с набором представлений как раз никогда не меняются независимо, всегда наоборот, и даже в самом тяжелом случае различаться будут не более чем на ~30%.

Изменен:07 дек 2016 18:25
 
 
Сообщения:577
Роман Осипов:
За трансформацию модели в ДТО отвечает именно представление, которое при необходимости можно заменить.

Нет у меня представления на стороне сервера. Приложение нормализованный JSON отдает (т.е. уже преобразованные данные), а его отображением клиентский JavaScript занимается.

upd: Ну или можно сказать что метод осуществляющий преобразование Entity->DTO и есть View.
Изменен:07 дек 2016 18:53
 
 
Сообщения:10008
wind:
И модель данных с набором представлений как раз никогда не меняются независимо, всегда наоборот, и даже в самом тяжелом случае различаться будут не более чем на ~30%
При построении API они всегда различаются и никогда наоборот. Разве что всем плевать на обратную совместимость API, но тогда нехватка DTO в проекте наверно не перво-приоритетная проблема :)

Хм.. и что 30% различий - это адекватная ситуация? Т.е. в классах у тебя +30% полей которые либо не нужны представлению, либо не нужны при сохранении? Это называется low cohesion и является негативной метрикой.
Плюс - надо как-то обходить ситуации когда в доменной модели у нас объекты и связи между ними, а в JSON'e или XML'e у нас ID'шки вместо объектов. Единственный вариант это как-то совместить с доменной моделью - это хранить ID'шки в самой модели (вместо объектов) либо добавлять специальные геттеры, а остальные геттеры игнорить для маршаллера.

В общем проблем огребается слишком много только ради того чтоб не создавать DTO..
Роман Осипов:
А чем не устраивает MVC? В контроллер вставляются зависимости от представления и модели. За трансформацию модели в ДТО отвечает именно представление, которое при необходимости можно заменить.
Хм.. это про какое MVC речь? Если про Model2, то там вьюхой будет JSP - туда логику трансформации не всунуть. Если MVP, то там еще не понятно куда совать ее - наверно в presenter? Но точно не во View. Если MVVM, то там ViewModel и будет DTO'шкой - и снова это не вью. Я короче не понял где все-таки MVC предлагает трансформировать в DTO и про какой MVC речь..
 
 
Сообщения:897
Староверъ:
wind:
И модель данных с набором представлений как раз никогда не меняются независимо, всегда наоборот, и даже в самом тяжелом случае различаться будут не более чем на ~30%
При построении API они всегда различаются и никогда наоборот. Разве что всем плевать на обратную совместимость API, но тогда нехватка DTO в проекте наверно не перво-приоритетная проблема :)

Хм.. и что 30% различий - это адекватная ситуация? Т.е. в классах у тебя +30% полей которые либо не нужны представлению, либо не нужны при сохранении? Это называется low cohesion и является негативной метрикой.
Плюс - надо как-то обходить ситуации когда в доменной модели у нас объекты и связи между ними, а в JSON'e или XML'e у нас ID'шки вместо объектов. Единственный вариант это как-то совместить с доменной моделью - это хранить ID'шки в самой модели (вместо объектов) либо добавлять специальные геттеры, а остальные геттеры игнорить для маршаллера.

В общем проблем огребается слишком много только ради того чтоб не создавать DTO..
Роман Осипов:
А чем не устраивает MVC? В контроллер вставляются зависимости от представления и модели. За трансформацию модели в ДТО отвечает именно представление, которое при необходимости можно заменить.
Хм.. это про какое MVC речь? Если про Model2, то там вьюхой будет JSP - туда логику трансформации не всунуть. Если MVP, то там еще не понятно куда совать ее - наверно в presenter? Но точно не во View. Если MVVM, то там ViewModel и будет DTO'шкой - и снова это не вью. Я короче не понял где все-таки MVC предлагает трансформировать в DTO и про какой MVC речь..


Да для Model2 view будет JSP. Но если смотреть шире, то работа шаблонизатора и преобразование в json/xml это один и тот-же процесс - процесс трансформации модели по набору каких-то правил к виду удобному для потребителя. Просто в одном случае потребитель это браузер, а в другом какая-то другая информационная система. А за представление данных отвечает view.
 
 
Сообщения:10008
Да, но в JSON мы преобразуем как раз DTO. А тема о том где этот самый DTO из Entity создать. Ну и с JSP то же самое - мы можем сам Entity передавать, а можем сначала сформировать "DTO" который осталось просто всунуть в нужное место в шаблоне.
Изменен:07 дек 2016 20:49
 
 
Сообщения:189
Староверъ:
Т.е. в классах у тебя +30% полей которые либо не нужны представлению, либо не нужны при сохранении? Это называется low cohesion и является негативной метрикой.

Нет, только для этих объектов будут особенные представления и/или сервисы. Что за метрики? Измеряется всё сугубо здравым смыслом. Если в проекте для сотни сущностей созданы еще по сотне dto / repository / service / еще чего-нибудь (еще и с разделением на интерфейс и реализацию), то либо люди вообще не понимают что делают, либо им просто нечего больше делать, либо им платят за тоннаж. Разумного в этом нет ничего.

Изменен:07 дек 2016 21:59
 
 
Сообщения:577
wind:
Если в проекте для сотни сущностей созданы еще по сотне dto / repository / service / еще чего-нибудь (еще и с разделением на интерфейс и реализацию), то либо люди вообще не понимают что делают, либо

Простите, но можете подсказать правильный с вашей точки зрения вариант.
В моем проекте N сущностей и N сервисов (и да, с разделением на интерфейс и реализацию), что я делаю не так и как надо?
 
 
Сообщения:897
Староверъ:
Да, но в JSON мы преобразуем как раз DTO. А тема о том где этот самый DTO из Entity создать. Ну и с JSP то же самое - мы можем сам Entity передавать, а можем сначала сформировать "DTO" который осталось просто всунуть в нужное место в шаблоне.
i
Я бы рассматривал DTO как некоторое представление модели, наряду с xml, json и т.д. Просто это представление не в виде строки, а в виде объекта.
 
 
Сообщения:1241
я cторонник варианта с магическими штуками, в частности Orika. Так как она достаточно гибкая в конфиге. Преобразования в обе стороны. Вариант с конструктором, который в качестве параметра принимает ДТО, предполагает, что если нужно сделать обратное преобразование, нужно делать аналогичный конструктор в доменном классе (например если у вас спринг и в контроллере араметры маппятся сами в ДТО, то из нее сразу получить доменный класс и сохранить его).

Если рассматривать варианты из первого поста, то Orika это гибрид 3 и 4 пунктов.
Изменен:08 дек 2016 11:58
 
 
Сообщения:577
masyan:
я cторонник варианта с магическими штуками, в частности Orika.

Спасибо, обязательно посмотрю. У меня как раз Spring и входные параметры в контроллерах маппятся в DTO.
 
 
Сообщения:189
izon:
В моем проекте N сущностей и N сервисов (и да, с разделением на интерфейс и реализацию), что я делаю не так и как надо?

Каждая из сущностей требует полностью уникальной логики для хранения/обработки? Религия против нестандартных проксей? В таких обстоятельствах всё как надо.

 
 
Сообщения:577
wind:
Каждая из сущностей требует полностью уникальной логики для хранения/обработки?

Ну в общем да. Исключение составляют несколько плоских справочников. Как вы предлагаете поступать с ними? Я без всякого сарказма спрашиваю, мне действительно интересно.
 
 
Сообщения:189
izon:
Ну в общем да.

Даже интересно стало. Одна хранится в обычной базе, другая в какой-нибудь вообще не-SQL, третья в xml-файле, четвертая после каждой модификации отправляется по почте, пятая хитрейшим образом кэшируется, шестая ... ? О_о Разве слегка иной набор атрибутов у той или иной сущности, хранящихся в 1 источнике данных является поводом нагородить отдельный компонент для работы с нею? О_о С какой целью?

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