B>Протокол обмена между представлением и бизнес логикой.
И все таки я не представляю что это за протокол. Можете описать пожалуйста, что он из себя представляет, простым языком?

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

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

GT>>Конфиги прошлый день! Сейчас рулят аннотации
B>Не особо-то они и рулят. Вот в чем проблема. У них куча побочных эффектов, с одним из которых вы как раз и боретесь.

Вы что-то путаете, мы боремся с написанием тупого кода пересечевания свойств между слоями. Аннотации нам в этом помогают.

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

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

SK>>>Соглашусь. Мэппинг все правно приходтся делать, и накой его делать в конфигах, если можно в коде, не понятно. Только головной боли прибавляет при дебаге.
SK>>>ЗЫ: Работал в конторе, где нанали дядьку который как раз это самый дозер написал, так как был там фанат этой фигни. Потом одумались, погнали вместе и дядьку и дозер
GT>>Конфиги прошлый день! Сейчас рулят аннотации

SK>Не вижу приципиальной разницы между одним и другим. Аннотации — тот же конфиг.
SK>А вообще, особенно здорово, выглядят аннотации когда их куча разных понавешано на одном класса. Например, ваши и хибернейтовские сразу. Уж лучше бы уж по разным файлам лежали.

Аннотации — это больше исключение, для тех случаев, когда без них нельзя обойтись. У нас к примеру может быть только 10% всех мапящихся полей в сущностях содержат аннотации для маппера. Кроме-то того аннотации находятся ближе к коду чем конфиги -> проще провести соответствие между полем/методом/классом и тем что эта аннотация выражает. Та что мне вам рассказывать очевидные вещи .. Весь мир переходит с конфигов на анноатции где это возможно — наверно дураки.

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

GT>Еще раз, как я вас понял.. Что якобы слои не нужны, надо маппинг доступа к бд, бизнес логикиу, и представление слепить в одну сущность. Сейчас же вы говорите что слои нужны.. Извините если не правильно понял.
Слои нужны. Не нужны копии слоёв. У вас 3 копии одного и того же слоя. И инструмент копирования между ними. А всё почему? Потому что бизнес модель какого-то невероятным образом отличается от модели БД и их нельзя замапить средствами работы с БД и приходится вводить новый слой. Аналогично и UI с какого-то перепугу не ложится на бизнес модель вообще и не может использовать всё её "гибкость".


GT>Отчего вы решили что вместо бизнес объектов у нас обрубки? "у меня на View есть PersonWithName" это вы про свой проект говорите, или иносказательно про мой?
Про ваш. У вас же "секурные" данные, которые нельзя отдавать на View слой. И если View слою нужно вычислить бизнес метод? У меня например, в бизнес-сущностях куча вычислимых свойств. Эти свойства вычисляются из нескольких связаных сущностей и их свойст. Эти свойства используются на всех уровнях, и на View и на бизнес-транзакциях и в ORM интерцепторах и на межсерверной синхронизации.
Вы же предлагаете под каждое такое вычислимое свойство заводить новое? Зачем? Это же как-то надо изолировать и контролировать чтобы оно было актуальным.

GT>Допустим про мой.. Итак есть бизнес объект PersonBO, и вьюшка PersonWithNameVO. Делаем в PersonBO метод вычисляющий возраст, и обзываем getAge(). Далее во вьюшке делаем свойство age. Все.
Куча лишних телодвижений. В то время как я добавляю вычислимое свойство getAge(), вам нужно добавить его в остальные слои как сосояние и проверить что маппинг копирует значение.

GT>Маппер замапит возраст на вьюшку. Нужен будет этот ворзаст в какой нибудь PersonFullInfoVO — тоже делается свойство age, или наследуется от PersonWithNameVO, тут по ситуации.
Понятно. По бритве Оккама моё решение лучше, потому что проще.

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


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

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

GT>Вы что-то путаете, мы боремся с написанием тупого кода пересечевания свойств между слоями. Аннотации нам в этом помогают.
А тупой код "пересечивания" на ровном месте возник? Или вы сами себе придумали архитектуру для которой он нужен?

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

GT>Аннотации — это больше исключение, для тех случаев, когда без них нельзя обойтись. У нас к примеру может быть только 10% всех мапящихся полей в сущностях содержат аннотации для маппера. Кроме-то того аннотации находятся ближе к коду чем конфиги -> проще провести соответствие между полем/методом/классом и тем что эта аннотация выражает. Та что мне вам рассказывать очевидные вещи ..
Аннотации, как и многое другое это палка о двух концах. С одной стороны, они действительно, проще контролируются легче кодируются и лучше поддерживаются в IDE.
С другой стороны они ограничены в средствах выражения. Сильно перегружают классы, когда мы их используем разными инструментами.

GT>Весь мир переходит с конфигов на анноатции где это возможно — наверно дураки.
У вас очень техническая аргументация, надо заметить. Давайте все же не скатываться в демагогию.
А то у меня тоже найдутся контр-аргументы в том же стиле.
http://lurkmore.to/95%25_%D0%BD%D0%B0%D1%81%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%E2%80%94_%D0%B8%D0%B4%D0%B8%D0%BE%D1%82%D1%8B

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

B>От себя хочу отметить, что в нормальном дизайне приложения такой ерунды как перекладывания свойств туда-сюда между (тремя!) слоями нет.
B>BO чудестно можно использовать на всех слоях вместо DTO и VO. Вводя последние лишь в отдельных случаях, когда нужна агрегация и специальная оптимизация.

Я вижу 2 применения этого маппера:
1) Генерация автоматического копирования полей базового класса в производный. Иногда такое приходится делать. В результате кода писать не нужно вообще, и гарантированно не ошибешься и при развитии не забудешь добавить какое то поле, если оно поменялось у базового класса;
2) Есть множество поставщиков данных. Данные из разных форматов гонятся в унифицированное внутреннее представление, а из внутреннего представления преобразуются в различные форматы множества потребителей этих данных. Поставщики данных и потребители — это совершенно независимые от нас приложения. Но названия кучи полей совпадает, в результате нужно ручками писать копирование только различающихся полей. При этом маппер автоматом сделает преобразование из одного типа данных в другой, например из XMLGregorianCalendar в Date;

Пункт 2 нужен довольно часто. Поставщики данных отдают одни данные, они зачастую избыточны. А клиенту нужно весьма ограниченное подмножство исходных данных, причем в фомату, удобному именно клиенту. Да и пункт 1 тоже периодически бывает нужен.

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

E>1) Генерация автоматического копирования полей базового класса в производный. Иногда такое приходится делать. В результате кода писать не нужно вообще, и гарантированно не ошибешься и при развитии не забудешь добавить какое то поле, если оно поменялось у базового класса;
Честно-говоря не очень понял. Когда и зачем такое нужно?

E>2) Есть множество поставщиков данных. Данные из разных форматов гонятся в унифицированное внутреннее представление, а из внутреннего представления преобразуются в различные форматы множества потребителей этих данных. Поставщики данных и потребители — это совершенно независимые от нас приложения. Но названия кучи полей совпадает, в результате нужно ручками писать копирование только различающихся полей. При этом маппер автоматом сделает преобразование из одного типа данных в другой, например из XMLGregorianCalendar в Date;
E>Пункт 2 нужен довольно часто. Поставщики данных отдают одни данные, они зачастую избыточны. А клиенту нужно весьма ограниченное подмножство исходных данных, причем в фомату, удобному именно клиенту. Да и пункт 1 тоже периодически бывает нужен.
С этим полностью согласен. Но, могу на вскидку вспомнить 3 примера, где мне нужно было гонять данные между двумя моделями. И ни в одном из этих случаем маппинг не помог бы — слишком велика разница между моделями.

Например на одно простое свойство в моей модели, нужно создать 2-3 бина и заполнить 2-3 свойства классами сгенерироваными JAXB/JAXWS. При том что модель одной и той же domain.
В другом случае, как я уже писал выше, мне нужно использовать Legacy DB наровне с актуальной. И в конвертации между двумя моделями есть куча кода преборазования типов и значений. Никаким маппером это не решается.

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

GT>>Ну если вы предлагаете использовать одну и ту же сущность. И вот представление меняется, занчит и сущность надо поменять, чтобы отдавать чуть другие данные.
B>Жесть какая-то. Представление берет любую сущность и представляет её в нужном виде. Почему из задачи поменять представление незаменимо следует "поменять сущность", мне не понятно.

Что такое "представление"? Это какой-то паттерн?

On 22.10.2013 11:28, Blazkowicz wrote:

> E>1) Генерация автоматического копирования полей базового класса в
> производный. Иногда такое приходится делать. В результате кода писать не
> нужно вообще, и гарантированно не ошибешься и при развитии не забудешь
> добавить какое то поле, если оно поменялось у базового класса;
> Честно-говоря не очень понял. Когда и зачем такое нужно?

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

--
WBR,
Serge.

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

vsb>Что такое "представление"? Это какой-то паттерн?
"представление" это (sic!) представление модели данных в какой либо форме. Например XML, HTML, GUI, PDF и т.п.
Подход, который я предлагаю это использовать, например, инструмент XML маппинга, чтобы получить из модели любой XML.
Подход, которы предлагает автор темы, это получить через Object Mapper другую модель, которая полностью идентична нужному XML формату и замапить её на XML тривиальным способом.
Мой посыл заключается в том, что если настолько XML радикально отличается от модели, что нужно писать кучу конвертационного кода, то Object Mapper точно так же не справиться с копированием из одной модели в другую.

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

SK>>Не вижу приципиальной разницы между одним и другим. Аннотации — тот же конфиг.
SK>>А вообще, особенно здорово, выглядят аннотации когда их куча разных понавешано на одном класса. Например, ваши и хибернейтовские сразу. Уж лучше бы уж по разным файлам лежали.

GT>Аннотации — это больше исключение, для тех случаев, когда без них нельзя обойтись. У нас к примеру может быть только 10% всех мапящихся полей в сущностях содержат аннотации для маппера.
Случаи где не нужны аннтации леко покрываются че-то типа BeanUtils.copy. Не помню точно имя метода, но суть ясна.

GT>Кроме-то того аннотации находятся ближе к коду чем конфиги -> проще провести соответствие между полем/методом/классом и тем что эта аннотация выражает.
Никто не говорит, что они полное говно и не надо их использовать. Но как я уже упоминал и даже привел пример, не всегда аннотации это удобно. Еще, кстати, они ужасно не удобно, когда надо что-то поменять без перекомпиляции.

GT>Та что мне вам рассказывать очевидные вещи .. Весь мир переходит с конфигов на анноатции где это возможно — наверно дураки.
Это худщий аргумент, который можно придумать. Проще всего ошибиться как раз в чем-то очевидном.

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

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

GT>>Еще раз, как я вас понял.. Что якобы слои не нужны, надо маппинг доступа к бд, бизнес логикиу, и представление слепить в одну сущность. Сейчас же вы говорите что слои нужны.. Извините если не правильно понял.
B>Слои нужны. Не нужны копии слоёв. У вас 3 копии одного и того же слоя. И инструмент копирования между ними. А всё почему? Потому что бизнес модель какого-то невероятным образом отличается от модели БД и их нельзя замапить средствами работы с БД и приходится вводить новый слой. Аналогично и UI с какого-то перепугу не ложится на бизнес модель вообще и не может использовать всё её "гибкость".
С чего вы решили что у меня копии слоев?
Ну я приводил пример фрагмента нашей модели в UML модели и вьюшки для Employee. Что нужно выдернуть только несколько полей из развесистой иерархии. Хорошо, допустим пойдем по вашему пути. И отдадим клиенту, который может быть html, ftl, веб сервисом всего Employee, со всей иерархией данных. Как обеспечить то, клиент получит только те поля которые ему нужны, а к остальным не сможет никак доступиться (по соображением безопасности скажем).

GT>>Отчего вы решили что вместо бизнес объектов у нас обрубки? "у меня на View есть PersonWithName" это вы про свой проект говорите, или иносказательно про мой?
B>Про ваш. У вас же "секурные" данные, которые нельзя отдавать на View слой. И если View слою нужно вычислить бизнес метод? У меня например, в бизнес-сущностях куча вычислимых свойств. Эти свойства вычисляются из нескольких связаных сущностей и их свойст. Эти свойства используются на всех уровнях, и на View и на бизнес-транзакциях и в ORM интерцепторах и на межсерверной синхронизации.
B>Вы же предлагаете под каждое такое вычислимое свойство заводить новое? Зачем? Это же как-то надо изолировать и контролировать чтобы оно было актуальным.
Свойство заводится только на той вьюшке, где оно необходимо клиенту. Чтобы клиент получал только те данные, которые ему действительн нужны, и НЕ получал те данные которые не нужны. Контролировать актуальность будет маппер.


GT>>Допустим про мой.. Итак есть бизнес объект PersonBO, и вьюшка PersonWithNameVO. Делаем в PersonBO метод вычисляющий возраст, и обзываем getAge(). Далее во вьюшке делаем свойство age. Все.
B>Куча лишних телодвижений. В то время как я добавляю вычислимое свойство getAge(), вам нужно добавить его в остальные слои как сосояние и проверить что маппинг копирует значение.

GT>>Маппер замапит возраст на вьюшку. Нужен будет этот ворзаст в какой нибудь PersonFullInfoVO — тоже делается свойство age, или наследуется от PersonWithNameVO, тут по ситуации.
B>Понятно. По бритве Оккама моё решение лучше, потому что проще.
Ваше решение проще, но отдает примитивизмом. Для начала ответьте на вопросы выше, а потом посмотрим лучше оно или нет.

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

H>Коллега, ну чего вы горячитесь. Вам не нужно, а в ряде реальных проектов
H>это очень даже нужно. Библиотека на мой взгляд очень интересная в смысле
H>сокращения всякой раздражающей писанины, попробуем применить.
Я не горячусь. Я ищу истину. Вполне возможно что я ошибаюсь. Но если я не буду отстаивать свою точку зрения, мне никто не расскажет почему я ошибаюсь.
Если Mapper реально крут, что может намаппить ненамапливаемое (что вызывает у меня самые серьезные сомнения) , то можно действительно им заменить все слои. И не мучается с тем что у нас модели не совпадает с базой, или с XML.
Но я категарически не понимаю пользы от маппера, который просто копирует 90% свойств как они есть.

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

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


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

Ок, есть модель. Есть 3 веб сервиса и 2 клиента одних и тех же данных. Есть сущность X с которой работают веб сервиса, c полями field1, field2, field3.
Клиент 1 должен видеть только поля 1, 2, поле 3 для него секретно.
Клиент 2 должен видеть только 2, 3, поле 1 для него секретно.
Клиент 3 должен видеть только 1, 3, поле 2 для него секретно.
Как будете реализовывать такие требования?

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

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

SK>>>Не вижу приципиальной разницы между одним и другим. Аннотации — тот же конфиг.
SK>>>А вообще, особенно здорово, выглядят аннотации когда их куча разных понавешано на одном класса. Например, ваши и хибернейтовские сразу. Уж лучше бы уж по разным файлам лежали.

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

GT>>Аннотации — это больше исключение, для тех случаев, когда без них нельзя обойтись. У нас к примеру может быть только 10% всех мапящихся полей в сущностях содержат аннотации для маппера.
SK>Случаи где не нужны аннтации леко покрываются че-то типа BeanUtils.copy. Не помню точно имя метода, но суть ясна.

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

GT>>Кроме-то того аннотации находятся ближе к коду чем конфиги -> проще провести соответствие между полем/методом/классом и тем что эта аннотация выражает.
SK>Никто не говорит, что они полное говно и не надо их использовать. Но как я уже упоминал и даже привел пример, не всегда аннотации это удобно. Еще, кстати, они ужасно не удобно, когда надо что-то поменять без перекомпиляции.
Вы можете использовать osgi архитектуру, и перекомпилировать только модуль с малой частью модели. Потом обновить этот модуль на запущенном приложении. И если при этом правильно настроить маппер то все изменения в аннотациях будут подхвачены.

GT>>Та что мне вам рассказывать очевидные вещи .. Весь мир переходит с конфигов на анноатции где это возможно — наверно дураки.
SK>Это худщий аргумент, который можно придумать. Проще всего ошибиться как раз в чем-то очевидном.

Извините, просто иногда бесит говорить очевидные вещи. Я хоть и думаю своей головой, но стараюсь так же прислушиваться к мнению большинства. Т.к. программисты я считаю далеко не глупые люди.

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

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

H>>Коллега, ну чего вы горячитесь. Вам не нужно, а в ряде реальных проектов
H>>это очень даже нужно. Библиотека на мой взгляд очень интересная в смысле
H>>сокращения всякой раздражающей писанины, попробуем применить.
B>Я не горячусь. Я ищу истину. Вполне возможно что я ошибаюсь. Но если я не буду отстаивать свою точку зрения, мне никто не расскажет почему я ошибаюсь.
B>Если Mapper реально крут, что может намаппить ненамапливаемое (что вызывает у меня самые серьезные сомнения) , то можно действительно им заменить все слои. И не мучается с тем что у нас модели не совпадает с базой, или с XML.
B>Но я категарически не понимаю пользы от маппера, который просто копирует 90% свойств как они есть.

Приведите пожалуйста пример "ненамапливаемого". Вдруг маппер справится?)

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

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

B>>От себя хочу отметить, что в нормальном дизайне приложения такой ерунды как перекладывания свойств туда-сюда между (тремя!) слоями нет.
B>>BO чудестно можно использовать на всех слоях вместо DTO и VO. Вводя последние лишь в отдельных случаях, когда нужна агрегация и специальная оптимизация.

E>Я вижу 2 применения этого маппера:
E>1) Генерация автоматического копирования полей базового класса в производный. Иногда такое приходится делать. В результате кода писать не нужно вообще, и гарантированно не ошибешься и при развитии не забудешь добавить какое то поле, если оно поменялось у базового класса;
E>2) Есть множество поставщиков данных. Данные из разных форматов гонятся в унифицированное внутреннее представление, а из внутреннего представления преобразуются в различные форматы множества потребителей этих данных. Поставщики данных и потребители — это совершенно независимые от нас приложения. Но названия кучи полей совпадает, в результате нужно ручками писать копирование только различающихся полей. При этом маппер автоматом сделает преобразование из одного типа данных в другой, например из XMLGregorianCalendar в Date;

E>Пункт 2 нужен довольно часто. Поставщики данных отдают одни данные, они зачастую избыточны. А клиенту нужно весьма ограниченное подмножство исходных данных, причем в фомату, удобному именно клиенту. Да и пункт 1 тоже периодически бывает нужен.

Пункт 2 появляется практически повсеместно в интерпрайс приложениях. Трансформация данных является важной частью ESB архитектур. Я во многих приложениях встречал самописные трансформеры преобразующие данные из бизнес модели в представление (похоже что есть какое-то стандартное решение трансформации данных в .net и оно переносится в яву???) и зачастую в эти трансформеры просачивались элементы бизнес логики. Кроме того часто данные преобразуются из бизнес объектов в персистентную модель и ORM может помочь не во всех вопросах, тогда вместе с преобразованием в хранимые процедуры и триггера может утекать и бизнес логика.

Я так понимаю маппер должен более четко отделить обязанности преобразования данных от бизнес логики? И обеспечить возможность сохранить всю бизнес логику на одном слое?

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

Так а какой должна быть архитектура или специфика приложения чтобы использование маппера было выгодно?

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

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

И ещё вопрос возник.

context.getBeanClassMetadata(PersonView.class).property("firstName").mappedTo("name.firstName");

Лямбды будут?