Re[3]: Маппинг объектов с помощью java-object-merger - Java

Здравствуйте, GreenTea, Вы писали:

GT>С чего вы решили что у меня копии слоев?
Потому что 90% свойств копируется как есть.

GT>Ну я приводил пример фрагмента нашей модели в UML модели и вьюшки для Employee. Что нужно выдернуть только несколько полей из развесистой иерархии. Хорошо, допустим пойдем по вашему пути. И отдадим клиенту, который может быть html, ftl, веб сервисом всего Employee, со всей иерархией данных. Как обеспечить то, клиент получит только те поля которые ему нужны, а к остальным не сможет никак доступиться (по соображением безопасности скажем).
HTML рендерится на сервере? Тогда клиенту никакие лишние свойства в бразуер не попадуд.
FTL это что? Freemarker Template? Дык им тоже сервер владеет. Или мы уже беспокоимся о том что какие-то части сервера секурные, а какие-то нет?
SOAP, JSON представление реализуется через SOAP, JSON маппинг. То что на аннотациях нельзя замапить один объект в два разных JSON представления это как раз и есть косяк аннотаций и используемого фреймверка.

GT>Свойство заводится только на той вьюшке, где оно необходимо клиенту. Чтобы клиент получал только те данные, которые ему действительн нужны, и НЕ получал те данные которые не нужны. Контролировать актуальность будет маппер.
У нас уже есть куча мапперов — XML, JSON, ORM, зачем нам ещё один?

GT>Ваше решение проще, но отдает примитивизмом.
Давайте я промолчу чем отдаёт ваш подход?

GT>Для начала ответьте на вопросы выше, а потом посмотрим лучше оно или нет.
На все отвечаю по возможности.

Здравствуйте, GreenTea, Вы писали:

B>>Ну, давайте тогда конкретно. О каком именно UI речь?
Я вот вопрос задал, вроде как разговор поддерживал. Получил ответ ничем не связаный с обсуждением выше.

GT>Ок, есть модель. Есть 3 веб сервиса и 2 клиента одних и тех же данных. Есть сущность X с которой работают веб сервиса, c полями field1, field2, field3.
GT>Клиент 1 должен видеть только поля 1, 2, поле 3 для него секретно.
GT>Клиент 2 должен видеть только 2, 3, поле 1 для него секретно.
GT>Клиент 3 должен видеть только 1, 3, поле 2 для него секретно.
GT>Как будете реализовывать такие требования?
Пограничный случай, придуманый на ходу. Если field level security, то вешаем соответствующий фильтр, который не отдаёт клиентам то что им нельзя видеть.
Как я уже говорил выше, "секретность" это отдельный слой.
Завтра клиенту №2 нужно будет видеть поле №1 и вам придётся для этого пересобирать проект, а не просто добавить свойсво в ACL.

Здравствуйте, GreenTea, Вы писали:

GT>Приведите пожалуйста пример "ненамапливаемого". Вдруг маппер справится?)
Да, пожалуйста. Бизнес модель

class Availability{
   Calendar from;
   Calendar to;
}

Код конвертации в соответвующую WSDL модель:

GetUserAvailabilityRequestType getUserAvailabilityRequestType = new GetUserAvailabilityRequestType();
FreeBusyViewOptionsType freeBusyViewOptionsType = new FreeBusyViewOptionsType();
Duration duration = new Duration();
duration.setStartTime(DatatypeFactory.newInstance().newXMLGregorianCalendar((GregorianCalendar) from));
duration.setEndTime(DatatypeFactory.newInstance().newXMLGregorianCalendar((GregorianCalendar) to));
freeBusyViewOptionsType.setTimeWindow(duration);
getUserAvailabilityRequestType.setFreeBusyViewOptions(freeBusyViewOptionsType);

Здравствуйте, Hazeh, Вы писали:

H>Недостатки маппинга достаточно хорошо обсуждены, главный из них это невозможность выявления ошибок маппинга данных во время компиляции.
Я бы не сказал что это самый главный недостаток. Генерики и лямбды должны помочь лучше контролировать маппинг в compile-time.
Для меня главным недостатком является то, что все бизнес-методы остаются в бизнес-слоё и в пограничных слоях становятся недоступны, потому что там доступны только Data Transfer Object или Value Object или аналогичная ересь.

Здравствуйте, GreenTea, Вы писали:

GT>Мы такого стараемся не допускать. На хибернетовских сущностях хибернетовские, на вью объектах — аннотации маппера. И все выглядит чисто и замечательно.
О том и речь косяк аннотаций в том, что они не дают нормальной возможности замапить одни класс на два протокола.
Кроме этого они вас вынуждают заводить поля под вычислимые свойства. А это может привести к неконсистентности данных, когд значение копии вычислимого свойства не совпадает с состоянием объекта.

SK>>Случаи где не нужны аннтации леко покрываются че-то типа BeanUtils.copy. Не помню точно имя метода, но суть ясна.
Бинго!

GT>Согласен бин утилсами можно. Но маппер может так же много чего еще. К примеру мержить коллекции объектов. Вручную вам придется присать довольно шаблонный код для каждого свойства. Если бы в джаве были макросы, как в лиспе к примеру, то весь этот шаблонный код можно было бы оставить в макросе. Но мы программируем на джаве..
В статье стоило более детально остановитья на таких моментах.

GT>Извините, просто иногда бесит говорить очевидные вещи.
Это уже на религию смахивает. Вы правда считаете что правильность и непоколебимость вашего подхода очевидна?

GT>Я хоть и думаю своей головой, но стараюсь так же прислушиваться к мнению большинства.
Лемминги — любимая игра? Мнения большинства реально побоку. Есть мнение авторитетов, которое подкреплено аргументацией. Есть своё мнение. На мнение большинства наплевать.

GT>Т.к. программисты я считаю далеко не глупые люди.
Программисты, например, придумали null ссылку, которая стоит костью в горле индустрии уже не один десяток лет.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, GreenTea, Вы писали:

GT>>С чего вы решили что у меня копии слоев?
B>Потому что 90% свойств копируется как есть.

Да нет же! 90% полей которые нужны на вьюшке, мапятся автоматом, а для 10% нужно указывать аннотации чтобы как-то отконфигурить.. А на вьюшке могут быть нужны 5% полей из всей сущности модели, а может и все 100% тут как по требованиям — по разному бывает.

GT>>Ну я приводил пример фрагмента нашей модели в UML модели и вьюшки для Employee. Что нужно выдернуть только несколько полей из развесистой иерархии. Хорошо, допустим пойдем по вашему пути. И отдадим клиенту, который может быть html, ftl, веб сервисом всего Employee, со всей иерархией данных. Как обеспечить то, клиент получит только те поля которые ему нужны, а к остальным не сможет никак доступиться (по соображением безопасности скажем).
B>HTML рендерится на сервере? Тогда клиенту никакие лишние свойства в бразуер не попадуд.
B>FTL это что? Freemarker Template? Дык им тоже сервер владеет. Или мы уже беспокоимся о том что какие-то части сервера секурные, а какие-то нет?
B>SOAP, JSON представление реализуется через SOAP, JSON маппинг. То что на аннотациях нельзя замапить один объект в два разных JSON представления это как раз и есть косяк аннотаций и используемого фреймверка.

"То что на аннотациях нельзя замапить один объект в два разных JSON представления это как раз и есть косяк аннотаций" о чем я и говорю! Вешая аннотации на сущности мы задаем только 1 способ маппинга, а если нужно мапить одну и ту же сущность в разных местах двумя, тремя и более способами, то тут аннотации не помогут. Зато если ввести слой представлений (вьшек) и использовать маппер — то проблемма решается. А как вы решаете данною проблему, дождусь я от вас ответа или нет?

GT>>Свойство заводится только на той вьюшке, где оно необходимо клиенту. Чтобы клиент получал только те данные, которые ему действительн нужны, и НЕ получал те данные которые не нужны. Контролировать актуальность будет маппер.
B>У нас уже есть куча мапперов — XML, JSON, ORM, зачем нам ещё один?

Повторяю: вы не можете JSON маппером вешая аннотации настроить более 1 сособа, как эта сущность будет мапится.

GT>>Ваше решение проще, но отдает примитивизмом.
B>Давайте я промолчу чем отдаёт ваш подход?

GT>>Для начала ответьте на вопросы выше, а потом посмотрим лучше оно или нет.
B>На все отвечаю по возможности.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, GreenTea, Вы писали:

B>>>Ну, давайте тогда конкретно. О каком именно UI речь?
B>Я вот вопрос задал, вроде как разговор поддерживал. Получил ответ ничем не связаный с обсуждением выше.

GT>>Ок, есть модель. Есть 3 веб сервиса и 2 клиента одних и тех же данных. Есть сущность X с которой работают веб сервиса, c полями field1, field2, field3.
GT>>Клиент 1 должен видеть только поля 1, 2, поле 3 для него секретно.
GT>>Клиент 2 должен видеть только 2, 3, поле 1 для него секретно.
GT>>Клиент 3 должен видеть только 1, 3, поле 2 для него секретно.
GT>>Как будете реализовывать такие требования?
B>Пограничный случай, придуманый на ходу. Если field level security, то вешаем соответствующий фильтр, который не отдаёт клиентам то что им нельзя видеть.
B>Как я уже говорил выше, "секретность" это отдельный слой.
B>Завтра клиенту №2 нужно будет видеть поле №1 и вам придётся для этого пересобирать проект, а не просто добавить свойсво в ACL.

Как то вас уводит в сторону. Ладно, оставим в покое секюрити, есть wsdl — контракт с клиентом. И в wsdl прописано что
GT>>Клиент 1 должен видеть только поля 1, 2
GT>>Клиент 2 должен видеть только 2, 3
GT>>Клиент 3 должен видеть только 1, 3
Как будете делать?

Здравствуйте, GreenTea, Вы писали:

B>>То что на аннотациях нельзя замапить один объект в два разных JSON представления это как раз и есть косяк аннотаций и используемого фреймверка.
GT>"То что на аннотациях нельзя замапить один объект в два разных JSON представления это как раз и есть косяк аннотаций"
Не обязательно копировать мои цитаты, чтобы обернуть в кавычки. Движок форума подсвечивает цитаты, когда они начинаеются с >.

GT>о чем я и говорю! Вешая аннотации на сущности мы задаем только 1 способ маппинга, а если нужно мапить одну и ту же сущность в разных местах двумя, тремя и более способами, то тут аннотации не помогут.
И на помощь приходят конфиги и маппинг вне классов.

GT>Зато если ввести слой представлений (вьшек) и использовать маппер — то проблемма решается. А как вы решаете данною проблему, дождусь я от вас ответа или нет?
Вы требуете конкретики об абстракции? О какой конкретно технологии речь? JSON? HTML? Swing GUI? SOAP? Отчеты? Для каждого решается вопрос по-своему.

GT>Повторяю: вы не можете JSON маппером вешая аннотации настроить более 1 сособа, как эта сущность будет мапится.
Могу без аннотаций. Могу с аннотациями и security фильтром. Много как могу, в зависимости от требований системы.

Здравствуйте, Blazkowicz, Вы писали:

B>

B>GetUserAvailabilityRequestType getUserAvailabilityRequestType = new GetUserAvailabilityRequestType();
B>FreeBusyViewOptionsType freeBusyViewOptionsType = new FreeBusyViewOptionsType();
B>Duration duration = new Duration();
B>duration.setStartTime(DatatypeFactory.newInstance().newXMLGregorianCalendar((GregorianCalendar) from));
B>duration.setEndTime(DatatypeFactory.newInstance().newXMLGregorianCalendar((GregorianCalendar) to));
B>freeBusyViewOptionsType.setTimeWindow(duration);
B>getUserAvailabilityRequestType.setFreeBusyViewOptions(freeBusyViewOptionsType);
B>

А что мешает зарегистрировать конвертор из GregorianCalendar в XMLGregorianCalendar, в результате чего маппер автоматом будет преобразовывать из GregorianCalendar в XMLGregorianCalendar? И зарегистрировать кастомный конвертор из Availability в Duration? В результате чего классы будут прекрасно автоматом замаплены друг на друга, и если Class1 содержит поле field c типом Availability, а Class2 содержит такое же имя field но с типом Duration, то при копировании из Class1 в Class2 все пройдет автоматом. Там же не тупой маппинг идет, там еще и преобразование типов делается, и возможно кастомное, когда требуется.
Это имеет смысл делать, так как в твоем случае преобразование идет копипастом (DatatypeFactory.newInstance().newXMLGregorianCalendar((GregorianCalendar) from)), и кода даже в таком тривиальном примере придется написать меньше

Здравствуйте, GreenTea, Вы писали:

GT>Как то вас уводит в сторону.
Это вы в ветках теряетесь. В этой я спросил о какой конкретно технологии речь.

GT>Ладно, оставим в покое секюрити, есть wsdl — контракт с клиентом. И в wsdl прописано что
ОК. SOAP WSDL. WSDL кто контролирует? Мы или 3rd party?

GT>>>Клиент 1 должен видеть только поля 1, 2
GT>>>Клиент 2 должен видеть только 2, 3
GT>>>Клиент 3 должен видеть только 1, 3
GT>Как будете делать?
Либо маппинг на конфигурациях. Либо влоб, потому что маппинг вообще не спасает на таких случаях:
http://rsdn.ru/forum/java/5339172.1

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, GreenTea, Вы писали:

GT>>Приведите пожалуйста пример "ненамапливаемого". Вдруг маппер справится?)
B>Да, пожалуйста. Бизнес модель
B>

B>class Availability{
B>   Calendar from;
B>   Calendar to;
B>}
B>

B>Код конвертации в соответвующую WSDL модель:

B>

B>GetUserAvailabilityRequestType getUserAvailabilityRequestType = new GetUserAvailabilityRequestType();
B>FreeBusyViewOptionsType freeBusyViewOptionsType = new FreeBusyViewOptionsType();
B>Duration duration = new Duration();
B>duration.setStartTime(DatatypeFactory.newInstance().newXMLGregorianCalendar((GregorianCalendar) from));
B>duration.setEndTime(DatatypeFactory.newInstance().newXMLGregorianCalendar((GregorianCalendar) to));
B>freeBusyViewOptionsType.setTimeWindow(duration);
B>getUserAvailabilityRequestType.setFreeBusyViewOptions(freeBusyViewOptionsType);
B>

Если Availability маппится только на GetUserAvailabilityRequestType тогда ставим аннотации

class Availability{
   @Mapping("freeBusyViewOptions.timeWindow.startTime");
   Calendar from;

   @Mapping("freeBusyViewOptions.timeWindow.endTime");
   Calendar to;
}

И 1 раз на все приложение регистрируем конвертор типов из Calendar в XMLGregorianCalendar. Код приводить не буду, но это дело техники.
Далее:

context.map(availability, GetUserAvailabilityRequestType.class());

Но мне так не нравится, т.к. пришлось писать аннотации относящиеся ко view на модели. И к тому же Availability может мапится по разному на развые вьюшки.
Возникло это изза того что представление оказалось сложноее чем модель. Ситуация довольно редкая.

В этом случае проще сделать программный маппинг. Итак, вместо аннотаций:

BeanClassMetadata m = context.getBeanClassMetadata(Availability.class);
m.property("from").mappedTo("freeBusyViewOptions.timeWindow.startTime");
m.property("to").mappedTo("freeBusyViewOptions.timeWindow.startTime");
context.map(availability, GetUserAvailabilityRequestType.class());

Оцените насколько проще и понятней такой код, чем каша написанная у вас.

Здравствуйте, GreenTea, Вы писали:

GT>Здравствуйте, Blazkowicz, Вы писали:

B>>Здравствуйте, GreenTea, Вы писали:

GT>>>Приведите пожалуйста пример "ненамапливаемого". Вдруг маппер справится?)
B>>Да, пожалуйста. Бизнес модель
B>>

B>>class Availability{
B>>   Calendar from;
B>>   Calendar to;
B>>}
B>>

B>>Код конвертации в соответвующую WSDL модель:

B>>

B>>GetUserAvailabilityRequestType getUserAvailabilityRequestType = new GetUserAvailabilityRequestType();
B>>FreeBusyViewOptionsType freeBusyViewOptionsType = new FreeBusyViewOptionsType();
B>>Duration duration = new Duration();
B>>duration.setStartTime(DatatypeFactory.newInstance().newXMLGregorianCalendar((GregorianCalendar) from));
B>>duration.setEndTime(DatatypeFactory.newInstance().newXMLGregorianCalendar((GregorianCalendar) to));
B>>freeBusyViewOptionsType.setTimeWindow(duration);
B>>getUserAvailabilityRequestType.setFreeBusyViewOptions(freeBusyViewOptionsType);
B>>

GT>Если Availability маппится только на GetUserAvailabilityRequestType тогда ставим аннотации
GT>

GT>class Availability{
GT>   @Mapping("freeBusyViewOptions.timeWindow.startTime");
GT>   Calendar from;

GT>   @Mapping("freeBusyViewOptions.timeWindow.endTime");
GT>   Calendar to;
GT>}
GT>

GT>И 1 раз на все приложение регистрируем конвертор типов из Calendar в XMLGregorianCalendar. Код приводить не буду, но это дело техники.
GT>Далее:
GT>

GT>context.map(availability, GetUserAvailabilityRequestType.class());
GT>

GT>Но мне так не нравится, т.к. пришлось писать аннотации относящиеся ко view на модели. И к тому же Availability может мапится по разному на развые вьюшки.
GT>Возникло это изза того что представление оказалось сложноее чем модель. Ситуация довольно редкая.

GT>В этом случае проще сделать программный маппинг. Итак, вместо аннотаций:
GT>

GT>BeanClassMetadata m = context.getBeanClassMetadata(Availability.class);
GT>m.property("from").mappedTo("freeBusyViewOptions.timeWindow.startTime");
GT>m.property("to").mappedTo("freeBusyViewOptions.timeWindow.startTime");
GT>context.map(availability, GetUserAvailabilityRequestType.class());
GT>

GT>Оцените насколько проще и понятней такой код, чем каша написанная у вас.

Да опечатка, конечно же

m.property("to").mappedTo("freeBusyViewOptions.timeWindow.endTime");

Здравствуйте, Blazkowicz, Вы писали:

B>Для меня главным недостатком является то, что все бизнес-методы остаются в бизнес-слоё и в пограничных слоях становятся недоступны, потому что там доступны только Data Transfer Object или Value Object или аналогичная ересь.
А может не нужно фигачить бизнес методы прямо в Entity? А как нидь разграничить логику. Entity для храниния, DTO для для передачи, а бизнес логику помещать в отдельные классы что то типа EntityService. Да, если приложение тривиальное, то кода будет больше. Но в среднем и крупном приложении от этого будет весьма неслабая выгода.

Кроме того, пограничные слои, которые оперируют с DTO — им 100 лет не сдались эти бизнес методы. Пограничные слои в основном визуализацией занимаются этой уже подготовленной DTO. Если нужны бизнес методы — будет вызов идти к сервису бизнес логики, а он как раз будет оперировать не с DTO, а с самой что ни на есть Entity, и все методы будут доступны.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, GreenTea, Вы писали:

GT>>Как то вас уводит в сторону.
B>Это вы в ветках теряетесь. В этой я спросил о какой конкретно технологии речь.

GT>>Ладно, оставим в покое секюрити, есть wsdl — контракт с клиентом. И в wsdl прописано что
B>ОК. SOAP WSDL. WSDL кто контролирует? Мы или 3rd party?

А, давайте рассмотрим оба варианта.

GT>>>>Клиент 1 должен видеть только поля 1, 2
GT>>>>Клиент 2 должен видеть только 2, 3
GT>>>>Клиент 3 должен видеть только 1, 3
GT>>Как будете делать?
B>Либо маппинг на конфигурациях.
Маппинг на конфигурация это что? Конфиги писать?

B>Либо влоб, потому что маппинг вообще не спасает на таких случаях: http://rsdn.ru/forum/java/5339172.1
Спасет, читайте ответ.

Тоесть правильно я понял, вы знаете 1000 и 1 способ решать задачу на всех технологиях, причем способы различные? Я же предлагаю один унифицированный способ (раздаление на слои и использование маппера), которой будет подходить для всех технологий.

Здравствуйте, GreenTea, Вы писали:

GT>Чуть расширенная версия статьи с хабра, для тех кто еще не видел
GT>http://brunneng.blogspot.com/2013/10/java-object-merger.html
Писал подобную хрень (точнее просил написать других

).
Были мысли сделать навороченно, с конфигурированием, приблизительно что в этой либе. Потом подумал, что смысла не будет. И поставил только цель как можно ближе языку и как можно меньше конфигурирования, чтоб был один метод — copy(dest, src), плюс регистрация конверторов.

Соответственно:
1) Аннотации не нужны. Нет, аннотации пришлось сделать, но только для маппинга коллекций на коллекции, чтоб обойти ограничения языка, по причине того, что тип приемника не знаешь — erasure чтоб его.;
2) Конфигурирование полей какие на какие тоже не нужны. Ибо по объему кода будет аналогично, соответственно если нужна конверсия разных полей, то проще конвертор зарегистрировать и эти поля мапить явно, вызывая собственный маппер как помощник.

Короче, задача типичная, но ИМХО тяжеленный чуть ли не фреймворк тут не нужен. Достаточно весьма легкого утилитного класса.

Здравствуйте, elmal, Вы писали:

E>А может не нужно фигачить бизнес методы прямо в Entity?
Зачастую надо. Иначе можно свалиться в полностью Anemic модель, с такими косяками как
— монструозными вычислениями в Service с нарушением инкапсуляции (внутри классов та же логика выглядит, читается и поддерживается проще)
— необходимостью таскать за собой Service везде где вообще нужна логика — интерцеторы, GUI и пр.

E>А как нидь разграничить логику. Entity для храниния, DTO для для передачи, а бизнес логику помещать в отдельные классы что то типа EntityService.
Service это паттерн TransactionScript. Там живут бизнес транзакции. Вынос вообще всей логики из бизнес-объектов в Service приводит к трудно четаемому и слабо переиспользоваемому коду. И ещё к процедурному стилю.

E>Да, если приложение тривиальное, то кода будет больше. Но в среднем и крупном приложении от этого будет весьма неслабая выгода.
Тут походу каждый думает что у него не тривиальное крупное приложение, а у остальных поделка на коленке?

E>Кроме того, пограничные слои, которые оперируют с DTO — им 100 лет не сдались эти бизнес методы. Пограничные слои в основном визуализацией занимаются этой уже подготовленной DTO. Если нужны бизнес методы — будет вызов идти к сервису бизнес логики, а он как раз будет оперировать не с DTO, а с самой что ни на есть Entity, и все методы будут доступны.
Это не так. Я уже приводил примеры выше. ORM Interceptor оперирует одними бинами, а бизнес логика в других (как предлагает автор статьи). Service туда тянуть? Чтобы посчитать, например, возраст? Так сервис же у нас оперирует BO бинами. Что делать?
Аналогично на View слое. Вместо того чтобы дернуть вычислимое свойство у бина, мне нужно добавить это свойство в бин представления и убедится что его значение всегда синхронизировано с остальными данными.

Здравствуйте, GreenTea, Вы писали:

GT>Если Availability маппится только на GetUserAvailabilityRequestType тогда ставим аннотации
Откуда маппер знает как инстанциируются классы? Фабрики можно задавать?

GT>И 1 раз на все приложение регистрируем конвертор типов из Calendar в XMLGregorianCalendar. Код приводить не буду, но это дело техники.
Ну, на всё приложение не канает. Calendar-то имеет разные представления, в зависимости от слоя.

GT>Но мне так не нравится, т.к. пришлось писать аннотации относящиеся ко view на модели. И к тому же Availability может мапится по разному на развые вьюшки.
Решение прямо на поверхности! Вводим AvailabilityDTO, который мапим и на Availability и на GetUserAvailabilityRequestType?

GT>Возникло это изза того что представление оказалось сложноее чем модель. Ситуация довольно редкая.
Сплошь и рядом. И не важно сложнее она или проще. Важно что она другая.

GT>В этом случае проще сделать программный маппинг. Итак, вместо аннотаций:
GT>

GT>BeanClassMetadata m = context.getBeanClassMetadata(Availability.class);
GT>m.property("from").mappedTo("freeBusyViewOptions.timeWindow.startTime");
GT>m.property("to").mappedTo("freeBusyViewOptions.timeWindow.endTime");
GT>context.map(availability, GetUserAvailabilityRequestType.class);
GT>

GT>Оцените насколько проще и понятней такой код, чем каша написанная у вас.
Код лучше, я не спорю. Только всю гибкость мы просрали.
1) Если свойство — коллекция. Откуда маппер узнает нужно замапить на предыдущий элемент или новый добавить?
2) Если мне теперь ещё нужно добавить пару констант, которые имеют отношения только к представлению freeBusyViewOptions? Константы можно замапить?

Здравствуйте, elmal, Вы писали:

E>Здравствуйте, GreenTea, Вы писали:

GT>>Чуть расширенная версия статьи с хабра, для тех кто еще не видел
GT>>http://brunneng.blogspot.com/2013/10/java-object-merger.html
E>Писал подобную хрень (точнее просил написать других

).
E>Были мысли сделать навороченно, с конфигурированием, приблизительно что в этой либе. Потом подумал, что смысла не будет. И поставил только цель как можно ближе языку и как можно меньше конфигурирования, чтоб был один метод — copy(dest, src), плюс регистрация конверторов.

E>Соответственно:
E>1) Аннотации не нужны. Нет, аннотации пришлось сделать, но только для маппинга коллекций на коллекции, чтоб обойти ограничения языка, по причине того, что тип приемника не знаешь — erasure чтоб его.;
E>2) Конфигурирование полей какие на какие тоже не нужны. Ибо по объему кода будет аналогично, соответственно если нужна конверсия разных полей, то проще конвертор зарегистрировать и эти поля мапить явно, вызывая собственный маппер как помощник.

E>Короче, задача типичная, но ИМХО тяжеленный чуть ли не фреймворк тут не нужен. Достаточно весьма легкого утилитного класса.

Все зависит от требований к маппингу. Лучше чтобы инструмент немножко с запасом покрывал запросы к нему чем чуть не дотягивал. Кастомный конвертер для свойств нужен да, очень редко, но пусть лучше он будет, хуже не будет

. Кстати я свою библиотеку не назваю фреймворком. По сравнению с дозером она намного более легковесная. 50000 маппингов сложного объекта за 8 секунд, думаю для больниства проектов будет достаточно

Здравствуйте, GreenTea, Вы писали:

GT>Маппинг на конфигурация это что? Конфиги писать?
Пока ваш маппинг не имеет compile time check это всё тот же конфиг.
Только на аннотациях мы не можем иметь больше одного конфига.
А без них можем.

GT>Тоесть правильно я понял, вы знаете 1000 и 1 способ решать задачу на всех технологиях, причем способы различные? Я же предлагаю один унифицированный способ (раздаление на слои и использование маппера), которой будет подходить для всех технологий.
Нам повезло и мы Java, где вольны выбирать лучшие из инструментов. В противном случае, пришлось, бы, действительно, решать все проблемы введением всё новых и новых слоёв.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, GreenTea, Вы писали:

GT>>Если Availability маппится только на GetUserAvailabilityRequestType тогда ставим аннотации
B>Откуда маппер знает как инстанциируются классы? Фабрики можно задавать?

GT>>И 1 раз на все приложение регистрируем конвертор типов из Calendar в XMLGregorianCalendar. Код приводить не буду, но это дело техники.
B>Ну, на всё приложение не канает. Calendar-то имеет разные представления, в зависимости от слоя.

GT>>Но мне так не нравится, т.к. пришлось писать аннотации относящиеся ко view на модели. И к тому же Availability может мапится по разному на развые вьюшки.
B>Решение прямо на поверхности! Вводим AvailabilityDTO, который мапим и на Availability и на GetUserAvailabilityRequestType?

GT>>Возникло это изза того что представление оказалось сложноее чем модель. Ситуация довольно редкая.
B>Сплошь и рядом. И не важно сложнее она или проще. Важно что она другая.

GT>>В этом случае проще сделать программный маппинг. Итак, вместо аннотаций:
GT>>

GT>>BeanClassMetadata m = context.getBeanClassMetadata(Availability.class);
GT>>m.property("from").mappedTo("freeBusyViewOptions.timeWindow.startTime");
GT>>m.property("to").mappedTo("freeBusyViewOptions.timeWindow.endTime");
GT>>context.map(availability, GetUserAvailabilityRequestType.class);
GT>>

GT>>Оцените насколько проще и понятней такой код, чем каша написанная у вас.
B>Код лучше, я не спорю. Только всю гибкость мы просрали.
B>1) Если свойство — коллекция. Откуда маппер узнает нужно замапить на предыдущий элемент или новый добавить?
Маппить поле на коллекцию, это как? Можете поподробнее, или лучше напишите кодом.

B>2) Если мне теперь ещё нужно добавить пару констант, которые имеют отношения только к представлению freeBusyViewOptions? Константы можно замапить?
Вопрос, откуда эти константы будут браться? Если не из Availability и специфичны только для этого запроса то: засетить их вручную после маппинга.
Ибо это уже не функция маппера. Его задача перегнать данные из одного объекта в другой.

	От:	Blazkowicz
	Дата:	22.10.13 08:53
	Оценка:

	От:	Blazkowicz
	Дата:	22.10.13 08:55
	Оценка:

	От:	Blazkowicz
	Дата:	22.10.13 09:01
	Оценка:

	От:	Blazkowicz
	Дата:	22.10.13 09:04
	Оценка:

	От:	Blazkowicz
	Дата:	22.10.13 09:16
	Оценка: