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

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

GT>Чуть расширенная версия статьи с хабра, для тех кто еще не видел
GT>http://brunneng.blogspot.com/2013/10/java-object-merger.html
Потратив немного времени на изучение вопроса, вынужден признать, что object mapping имеет смысл, как раз в тех случаях когда используемые инструменты не дают возможности реализовать разнообразный маппинг для одних и тех же сущностей.
SOAP/WSDL выше не самый лучший пример. Например CXF позволяет задать маппинг через XML а не аннотации, соответственно это даёт возможность заиметь 3 контекста с разными маппингами, в зависимости от нужд. Я даже могу тоже самое через JAXB реализацию com.sun.* провернуть. Просто маппинг там придется сленка расковырять через рефлексию. Но задача решаема.
Но тем неменее, возможно, существуют инструменты, где так просто тоже самое не реализовать. Например недавно столкнулся с JavaFX 2 вплотную. Где совершенно не понятно какая стратегия лучше, то ли MVVM, с дублированием сущностей, то ли использование javafx свойств, там где они отрадась ненужны. В случае MVVM, возможно, маппер бы и подлечил.

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

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

GT>>Чуть расширенная версия статьи с хабра, для тех кто еще не видел
GT>>http://brunneng.blogspot.com/2013/10/java-object-merger.html
B>Статья как раз для хабра. У вас есть кривой код? У нас есть для него фреймверк!

На хабре уже есть более ранняя версия этой статьи.

B>В итоге может оказатся, что существенной разницы между
B>

B>personVO.setFirstName(person.getFirstName());
B>person.setFirstName(personVO.getFirstName());
B>

B>супротив аналогичного кода на API маппера не имеется.

Для случая совпадения имен между полями на API маппера вообще ничего не нужно делать. Это определяется автоматически.

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

Все зависит от размера приложения. Если что-то мелкое — то да. А если одни и те же данные имеют множество представлений в разных местах, то приходится вводить вьюшки. Та и если вы веб сервиса пишете где нужно просто иначе группировать данные, и dto шки для него генерятся по wsdl.. Насчет 3 слоев, это я описал все таки крайний случай, на моей практике маппинг был максимум между 2 слоями.

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

GT>Для случая совпадения имен между полями на API маппера вообще ничего не нужно делать. Это определяется автоматически.
Я понимаю. Просто когда модель идентичная, то такой код больше смахивает на промах в проектировании. Когда модель разная, то выгода от маппинге невидируется тем что нужно ещё иметь слой адаптации в тех точках где модели различаются.

GT>Все зависит от размера приложения. Если что-то мелкое — то да.
Не вижу связи.

GT>А если одни и те же данные имеют множество представлений в разных местах, то приходится вводить вьюшки.
Не вижу свяази. У меня толстый GUI, Web, DB, Legacy DB — представлений достаточно.
Похожий код если для конвертации представлений Legacy DB и актуальной DB. Но там маппер не лечит, так как нужно делать массу дополнительных приседаний, а не просто перекладывать свойства.

GT>Та и если вы веб сервиса пишете где нужно просто иначе группировать данные, и dto шки для него генерятся по wsdl..
Если это 3rd party WSDL, то обычно его модель на столько не совпадает с разрабатываемой системной, что простым маппингом это не лечится.
Если это "наша" подконтрольная WSDL, то не вижу причин не использовать одни и те же бины в других слоях.

GT>Насчет 3 слоев, это я описал все таки крайний случай, на моей практике маппинг был максимум между 2 слоями.
Мне однажды достался проект с таким "крайним случаем". Никаких принципиальных преимуществ в таком подходе я не заметил.

Впрочем, я вынужден признать, что у дизайна, с одной и той же моделью на всех слоях есть свои недостатки. Но! Они все вызваны именно тем что инструментарий не предусматривает того что эти классы могуть быть использованы 3-мя, 4-мя аналогичными инструментариями. Таким образом надобность в DTO клона, обычно, вызвано используемыми библиотеками, а не тем что это даёт каких-то преимуществ.

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

GT>Все зависит от размера приложения. Если что-то мелкое — то да. А если одни и те же данные имеют множество представлений в разных местах, то приходится вводить вьюшки. Та и если вы веб сервиса пишете где нужно просто иначе группировать данные, и dto шки для него генерятся по wsdl.. Насчет 3 слоев, это я описал все таки крайний случай, на моей практике маппинг был максимум между 2 слоями.

Вот в этом сообщении есть ссылки на две больших темы по DTO, так как DTO наиболее яркий представитель, которому требование копирование свойств.
http://www.rsdn.ru/forum/design/3818228.1
Если интересно разобраться в вопросе, рекомендую почитать.

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

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

GT>>Для случая совпадения имен между полями на API маппера вообще ничего не нужно делать. Это определяется автоматически.
B>Я понимаю. Просто когда модель идентичная, то такой код больше смахивает на промах в проектировании. Когда модель разная, то выгода от маппинге невидируется тем что нужно ещё иметь слой адаптации в тех точках где модели различаются.

"Слой адаптации" при использовании маппера это аннотации к сущности на одном из своев. Ничего военного. Вы рассматриваете 2 крайних случая. А бывает так что объекты между слоями на 90% похожи на 10% различны по структуре. На моей практике так и бывало. И для такого как раз мапперы очень облегчают жизнь.

GT>>Все зависит от размера приложения. Если что-то мелкое — то да.
B>Не вижу связи.

GT>>А если одни и те же данные имеют множество представлений в разных местах, то приходится вводить вьюшки.
B>Не вижу свяази. У меня толстый GUI, Web, DB, Legacy DB — представлений достаточно.
B>Похожий код если для конвертации представлений Legacy DB и актуальной DB. Но там маппер не лечит, так как нужно делать массу дополнительных приседаний, а не просто перекладывать свойства.

Возможно это специфика толстого клиента. Поверьте, мешать маппинг в базу, бизнес логику, и представление в одной сущности — как раз это ошибка дизайна. У нас такое было один раз, так что обычные сущности со временем распухали до 1.5к строчек кода, и понять что то было уже не возможно. Насчет большой апликухи я не зря сказал. По началу может модели в базе и на вьюхе не будут различаться, но потом с новыми требованиями различия будут накапливаться, вводится дополнительные вьюшки, меняться представление уже имеющихся данных. Где то репорт потребуется сгенерить, а там вдруг данные представляются совсем не так как в базе! А код, если изначально не разбить на слои, будет ухудшаться все больше.

GT>>Та и если вы веб сервиса пишете где нужно просто иначе группировать данные, и dto шки для него генерятся по wsdl..
B>Если это 3rd party WSDL, то обычно его модель на столько не совпадает с разрабатываемой системной, что простым маппингом это не лечится.
B>Если это "наша" подконтрольная WSDL, то не вижу причин не использовать одни и те же бины в других слоях.

Ну представте типичный случай, что на веб сервисе есть 2 метода: первый возвращает всю сущность по id, второй возвращает по критерию поиска — список всех сущностей в укороченном виде (несколько самых важных полей).

GT>>Насчет 3 слоев, это я описал все таки крайний случай, на моей практике маппинг был максимум между 2 слоями.
B>Мне однажды достался проект с таким "крайним случаем". Никаких принципиальных преимуществ в таком подходе я не заметил.

B>Впрочем, я вынужден признать, что у дизайна, с одной и той же моделью на всех слоях есть свои недостатки. Но! Они все вызваны именно тем что инструментарий не предусматривает того что эти классы могуть быть использованы 3-мя, 4-мя аналогичными инструментариями. Таким образом надобность в DTO клона, обычно, вызвано используемыми библиотеками, а не тем что это даёт каких-то преимуществ.

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

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

GT>>http://brunneng.blogspot.com/2013/10/java-object-merger.html

B>В итоге может оказатся, что существенной разницы между
B>

B>personVO.setFirstName(person.getFirstName());
B>person.setFirstName(personVO.getFirstName());
B>

B>супротив аналогичного кода на API маппера не имеется.

Соглашусь. Мэппинг все правно приходтся делать, и накой его делать в конфигах, если можно в коде, не понятно. Только головной боли прибавляет при дебаге.

ЗЫ: Работал в конторе, где нанали дядьку который как раз это самый дозер написал, так как был там фанат этой фигни. Потом одумались, погнали вместе и дядьку и дозер

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

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

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

GT>>>http://brunneng.blogspot.com/2013/10/java-object-merger.html

B>>В итоге может оказатся, что существенной разницы между
B>>

B>>personVO.setFirstName(person.getFirstName());
B>>person.setFirstName(personVO.getFirstName());
B>>

B>>супротив аналогичного кода на API маппера не имеется.

SK>Соглашусь. Мэппинг все правно приходтся делать, и накой его делать в конфигах, если можно в коде, не понятно. Только головной боли прибавляет при дебаге.

SK>ЗЫ: Работал в конторе, где нанали дядьку который как раз это самый дозер написал, так как был там фанат этой фигни. Потом одумались, погнали вместе и дядьку и дозер

Конфиги прошлый день! Сейчас рулят аннотации

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

GT>"Слой адаптации" при использовании маппера это аннотации к сущности на одном из своев. Ничего военного. Вы рассматриваете 2 крайних случая. А бывает так что объекты между слоями на 90% похожи на 10% различны по структуре. На моей практике так и бывало. И для такого как раз мапперы очень облегчают жизнь.
В этом случае 90% кода можно вынести в общие классы. Сюрприз!

GT>Возможно это специфика толстого клиента.
На Web тоже самое. На Web Service — тоже самое. На RMI тоже самое.

GT>Поверьте, мешать маппинг в базу, бизнес логику, и представление в одной сущности — как раз это ошибка дизайна.
"У нас тут все джентельмены — верят друг-другу на слово". Да?
У меня куча бинов предметной области с маппингами, логикой и пр. В чем ошибка? Как я уже написал выше, косяки вылазят только на кривых инструментах, которые думают что они единолично владеют этими объектами и делают с ним что угодно.

GT>У нас такое было один раз, так что обычные сущности со временем распухали до 1.5к строчек кода, и понять что то было уже не возможно.
Выкладывай класс, я расскажу что с ним не так.

GT>Насчет большой апликухи я не зря сказал.
ОК. Возможно. На больших приложениях косяки всплывают с большей вероятностью.

GT>По началу может модели в базе и на вьюхе не будут различаться, но потом с новыми требованиями различия будут накапливаться, вводится дополнительные вьюшки, меняться представление уже имеющихся данных.
Давайте конкретный пример обсудим. То есть у нас на View совсем не то что в базе? То есть кто-то из двух тупо игнорирует Domain Model? Или как это?

GT>Где то репорт потребуется сгенерить, а там вдруг данные представляются совсем не так как в базе! А код, если изначально не разбить на слои, будет ухудшаться все больше.
Domain Model это отдельный слой. Код разбит на слои. Зачем иметь 3 слоя Domain Model — не понимаю. Пример с отчетом не понятен в двойне. Отчет в любом случае генерится по базе.

GT>Ну представте типичный случай, что на веб сервисе есть 2 метода: первый возвращает всю сущность по id, второй возвращает по критерию поиска — список всех сущностей в укороченном виде (несколько самых важных полей).
Офигить и в WSDL они описаны как 2 разных типа??? PersonFull, PersonPartial, PersonForReport, PersonForView... Класс.

Это всё приводит к тому что ни на уровне работы с базой, ни на уровне представления вы не можете использовать бизнес логику и она начинает странным способом размазываться по слоям.
То есть, нужно например написать Interceptor для Hibernate. И в нем выполнить логику. То мы в нем получаем бин одного типа (база данных). Копируем в бин другого типа (бизнес логика). Вы полняем логику. Конвертируем обратно. Так?

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

GT>Конфиги прошлый день! Сейчас рулят аннотации

Не особо-то они и рулят. Вот в чем проблема. У них куча побочных эффектов, с одним из которых вы как раз и боретесь.

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

B>>Статья как раз для хабра. У вас есть кривой код? У нас есть для него фреймверк!
GT>На хабре уже есть более ранняя версия этой статьи.
Я имел ввиду что статья как раз уровня хабра. Читать там что либо о программировании можно только начинающим.

B>>В итоге может оказатся, что существенной разницы между
B>>

B>>personVO.setFirstName(person.getFirstName());
B>>person.setFirstName(personVO.getFirstName());
B>>

B>>супротив аналогичного кода на API маппера не имеется.
GT>Для случая совпадения имен между полями на API маппера вообще ничего не нужно делать. Это определяется автоматически.
Мне вот подумалось. Это ж мы на каждый запрос ещё и минимум два раза через рефлексию ходим? Для десятков и сотен свойств. Да?

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

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

GT>>"Слой адаптации" при использовании маппера это аннотации к сущности на одном из своев. Ничего военного. Вы рассматриваете 2 крайних случая. А бывает так что объекты между слоями на 90% похожи на 10% различны по структуре. На моей практике так и бывало. И для такого как раз мапперы очень облегчают жизнь.
B>В этом случае 90% кода можно вынести в общие классы. Сюрприз!

Не, не, не. Возможно не так выразился. Я имел в виду что для одной и той же вьюхи 90% полей совпадают, а 10% отличаются (типа: берутся из вложенных сущностей, конвертируется представление [к примеру для даты]).

GT>>Возможно это специфика толстого клиента.
B>На Web тоже самое. На Web Service — тоже самое. На RMI тоже самое.

GT>>Поверьте, мешать маппинг в базу, бизнес логику, и представление в одной сущности — как раз это ошибка дизайна.
B>"У нас тут все джентельмены — верят друг-другу на слово". Да?
B>У меня куча бинов предметной области с маппингами, логикой и пр. В чем ошибка? Как я уже написал выше, косяки вылазят только на кривых инструментах, которые думают что они единолично владеют этими объектами и делают с ним что угодно.

GT>>У нас такое было один раз, так что обычные сущности со временем распухали до 1.5к строчек кода, и понять что то было уже не возможно.
B>Выкладывай класс, я расскажу что с ним не так.

Это было давно. Сейчас к сожалению нету доступа к тому коду.

GT>>Насчет большой апликухи я не зря сказал.
B>ОК. Возможно. На больших приложениях косяки всплывают с большей вероятностью.

GT>>По началу может модели в базе и на вьюхе не будут различаться, но потом с новыми требованиями различия будут накапливаться, вводится дополнительные вьюшки, меняться представление уже имеющихся данных.
B>Давайте конкретный пример обсудим. То есть у нас на View совсем не то что в базе? То есть кто-то из двух тупо игнорирует Domain Model? Или как это?

Есть такая книжечка как Data model resource book (vol 1, 2, 3), там описаны правильные проверенные сопособы огранизации модели в бд для разных предметных областей. Когда мы начали делать нашу медицинскую систему (EMR) то черпали вдохновение из этой книжки. По началу, было совсем не понятно какой модель должна быть сейчас и как она изменится в будующем, т.к. четких требований как таковых к системе не было, и все менялось очень быстро. Поэтому модель делалась очень гибкой, с обилием объектов связок. Это трудно объеснить в паре предложений.
Та к книжку отправлять вас читать — мне честно, жалко. Т.к. она имеет свойство снотворного при ее чтении

. Что же получилось. Модель действительно очень гибкая, масштабируемая и удобная для описания бизнес логики. НО! Совершенно не мапится на представление один к одному. Аналитики составляющие требование — класть хотели на нашу супер модель.
Вот скриншот малой части модели..
https://www.dropbox.com/s/olgcy4vx3grlwl3/123.png

А теперь представте что надо вставить данные по сотруднику, его имя, должность, телефон. Это все берется из различный сущностей иерархии модели.

GT>>Где то репорт потребуется сгенерить, а там вдруг данные представляются совсем не так как в базе! А код, если изначально не разбить на слои, будет ухудшаться все больше.
B>Domain Model это отдельный слой. Код разбит на слои. Зачем иметь 3 слоя Domain Model — не понимаю. Пример с отчетом не понятен в двойне. Отчет в любом случае генерится по базе.

GT>>Ну представте типичный случай, что на веб сервисе есть 2 метода: первый возвращает всю сущность по id, второй возвращает по критерию поиска — список всех сущностей в укороченном виде (несколько самых важных полей).
B>Офигить и в WSDL они описаны как 2 разных типа??? PersonFull, PersonPartial, PersonForReport, PersonForView... Класс.
Ну представте себе да, а вы бы как делали?

B>Это всё приводит к тому что ни на уровне работы с базой, ни на уровне представления вы не можете использовать бизнес логику и она начинает странным способом размазываться по слоям.
B>То есть, нужно например написать Interceptor для Hibernate. И в нем выполнить логику. То мы в нем получаем бин одного типа (база данных). Копируем в бин другого типа (бизнес логика). Вы полняем логику. Конвертируем обратно. Так?

Не совсем, в текущем проекте бизнес объект оборачивается вокруг объекта базы. И работает как прокси. Тут маппинга нет.

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

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

B>>>Статья как раз для хабра. У вас есть кривой код? У нас есть для него фреймверк!
GT>>На хабре уже есть более ранняя версия этой статьи.
B>Я имел ввиду что статья как раз уровня хабра. Читать там что либо о программировании можно только начинающим.

B>>>В итоге может оказатся, что существенной разницы между
B>>>

B>>>personVO.setFirstName(person.getFirstName());
B>>>person.setFirstName(personVO.getFirstName());
B>>>

B>>>супротив аналогичного кода на API маппера не имеется.
GT>>Для случая совпадения имен между полями на API маппера вообще ничего не нужно делать. Это определяется автоматически.
B>Мне вот подумалось. Это ж мы на каждый запрос ещё и минимум два раза через рефлексию ходим? Для десятков и сотен свойств. Да?

Да, но маппинг объектов не является узким местом. Запросы к базе с последующим маппингом на сущности работают в десятки если не сотни раз медленнее.

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

B>>В этом случае 90% кода можно вынести в общие классы. Сюрприз!
GT>Не, не, не. Возможно не так выразился. Я имел в виду что для одной и той же вьюхи 90% полей совпадают, а 10% отличаются (типа: берутся из вложенных сущностей, конвертируется представление [к примеру для даты]).
И даже в этом случае 90% кода можно вынести в общие классы.

GT>Поэтому модель делалась очень гибкой...
GT>Совершенно не мапится на представление один к одному. Аналитики составляющие требование — класть хотели на нашу супер модель.
Ну, то есть, в итоге, модель оказалась недостаточно гибкой.

GT>https://www.dropbox.com/s/olgcy4vx3grlwl3/123.png
Ага. Теперь понятно чем руководствуются правительственные моделлеры в USA.

GT>А теперь представте что надо вставить данные по сотруднику, его имя, должность, телефон. Это все берется из различный сущностей иерархии модели.
Мне представлять не нужно. В UI нет проблем достать что-то через пару свойств.

GT>Ну представте себе да, а вы бы как делали?
Разбил бы через композицию и наследование в иерархию.

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

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

B>>>В этом случае 90% кода можно вынести в общие классы. Сюрприз!
GT>>Не, не, не. Возможно не так выразился. Я имел в виду что для одной и той же вьюхи 90% полей совпадают, а 10% отличаются (типа: берутся из вложенных сущностей, конвертируется представление [к примеру для даты]).
B>И даже в этом случае 90% кода можно вынести в общие классы.

GT>>Поэтому модель делалась очень гибкой...
GT>>Совершенно не мапится на представление один к одному. Аналитики составляющие требование — класть хотели на нашу супер модель.
B>Ну, то есть, в итоге, модель оказалась недостаточно гибкой.

Та нет, модель как раз это самое гибкое. А представление может меняться от итерации к итерации. Что же каждый раз базу менять?

GT>>https://www.dropbox.com/s/olgcy4vx3grlwl3/123.png
B>Ага. Теперь понятно чем руководствуются правительственные моделлеры в USA.

Зато теперь вы видите, что модели могут быть сложными. А то такое ощущение у меня сложилось, что вы живете в каком то простом мире

GT>>А теперь представте что надо вставить данные по сотруднику, его имя, должность, телефон. Это все берется из различный сущностей иерархии модели.
B>Мне представлять не нужно. В UI нет проблем достать что-то через пару свойств.

Ага, тянуть на представления всю иерархию, и пусть ищут, что им нужно! Отличный подход! А то что лишние данные передаются, то что это как минимум не секюрно, кого это волнует?)

GT>>Ну представте себе да, а вы бы как делали?
B>Разбил бы через композицию и наследование в иерархию.

Ок. На одном экране нужны условно поля field1, field2. На другом field2, field3, на третьем field1, field3. На самом деле под полями могут подразумеваться данные которые нужно вытащить из вложенных сущностей. И удачи вам в разбиении "через композицию и наследование в иерархию"

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

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

GT>Конфиги прошлый день! Сейчас рулят аннотации

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

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

GT>Та нет, модель как раз это самое гибкое. А представление может меняться от итерации к итерации. Что же каждый раз базу менять?
Хорошо, так если модель гибкая, то зачем менять её и базу для каждого представления?

GT>Зато теперь вы видите, что модели могут быть сложными. А то такое ощущение у меня сложилось, что вы живете в каком то простом мире

Ну, давайте письками меряться:
http://www.schemacentral.com/sc/niem21/ss.html

GT>Ага, тянуть на представления всю иерархию, и пусть ищут, что им нужно!
Зачем всю. Только ту часть, которая нужна.

GT>Отличный подход! А то что лишние данные передаются, то что это как минимум не секюрно, кого это волнует?)
Класс. То есть секурити, которая динамически на кладывается на мета-модель, у вас статически зашита в саму модель?

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

То есть, если я правильно понял, так как вам тяжело на UI работать с иерархией вы её приводите к плоской модели каждый раз? Это специфика UI такая?

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

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

GT>>Та нет, модель как раз это самое гибкое. А представление может меняться от итерации к итерации. Что же каждый раз базу менять?
B>Хорошо, так если модель гибкая, то зачем менять её и базу для каждого представления?
Ну если вы предлагаете использовать одну и ту же сущность. И вот представление меняется, занчит и сущность надо поменять, чтобы отдавать чуть другие данные. Но это означает и базу придется менять, тк. представление уже не соответсвует модели.

GT>>Зато теперь вы видите, что модели могут быть сложными. А то такое ощущение у меня сложилось, что вы живете в каком то простом мире

B>Ну, давайте письками меряться:
B>http://www.schemacentral.com/sc/niem21/ss.html
Честно, не понял что это такое.

GT>>Ага, тянуть на представления всю иерархию, и пусть ищут, что им нужно!
B>Зачем всю. Только ту часть, которая нужна.

GT>>Отличный подход! А то что лишние данные передаются, то что это как минимум не секюрно, кого это волнует?)
B>Класс. То есть секурити, которая динамически на кладывается на мета-модель, у вас статически зашита в саму модель?
Я к тому что если передавать всю иерархию сущностей как есть, то можно передать ненароком секретные данные.

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

B>То есть, если я правильно понял, так как вам тяжело на UI работать с иерархией вы её приводите к плоской модели каждый раз? Это специфика UI такая?

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

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

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

GT>Но это означает и базу придется менять, тк. представление уже не соответсвует модели.
Блин, слои для того и придумали, чтобы изменение одного слоя ограничивало "плюх" эти слоем. Почему у вас при изменении представления нужно менять модель предметной области и базу, мне не понятно.

B>>http://www.schemacentral.com/sc/niem21/ss.html
GT>Честно, не понял что это такое.
Это модель предметой области.

GT>Я к тому что если передавать всю иерархию сущностей как есть, то можно передать ненароком секретные данные.
Ненароком можно передать всё что хочешь. Если нужна секурность на уровне свойств, то почему бы её и не реализовать отдельным слоем, который даёт\запрещает достум к свойствам.
Я не вижу смысла хардкодить в модели то что динамически меняеться конфигурацией.
Даже если нужны секурные свойства. ОК.
FullPerson -> SecuredPersonInfo -> PublicPersonInfo -> BasicPersonInfo

GT>Тоесть насколько я понял, вы предлагаете не меняя исходной структуры модели передавать каждый раз только те данные которые нужны представлению. А кто будет решать какие данные нужны а какие нет, для каждого конкретного запроса, и кто это будет разруливать?
Протокол обмена между представлением и бизнес логикой. Мне воот теперь вообще интересно посмотреть на вашу бизнес логику. Она у вас, скорее, выходит совершенно анемичной.
К примеру, у меня на View есть PersonWithName, в котором нет DOB, потому что он в SecuredPersonInfo.
В результате мне чтобы посчитать AGE нельзя просто взять Person.calcAge(), мне нужно дописать Age в PersonWithName, и в маппинге.
Я уже задал этот вопрос выше. Как вы переиспользуете логику бизнес-объектов в слоях, где у вас вместо бизнес-объектов лишь обрубки?

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

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

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

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

Еще раз, как я вас понял.. Что якобы слои не нужны, надо маппинг доступа к бд, бизнес логикиу, и представление слепить в одну сущность. Сейчас же вы говорите что слои нужны.. Извините если не правильно понял.

B>>>http://www.schemacentral.com/sc/niem21/ss.html
GT>>Честно, не понял что это такое.
B>Это модель предметой области.

GT>>Я к тому что если передавать всю иерархию сущностей как есть, то можно передать ненароком секретные данные.
B>Ненароком можно передать всё что хочешь. Если нужна секурность на уровне свойств, то почему бы её и не реализовать отдельным слоем, который даёт\запрещает достум к свойствам.
B>Я не вижу смысла хардкодить в модели то что динамически меняеться конфигурацией.
B>Даже если нужны секурные свойства. ОК.
B>FullPerson -> SecuredPersonInfo -> PublicPersonInfo -> BasicPersonInfo

GT>>Тоесть насколько я понял, вы предлагаете не меняя исходной структуры модели передавать каждый раз только те данные которые нужны представлению. А кто будет решать какие данные нужны а какие нет, для каждого конкретного запроса, и кто это будет разруливать?
B>Протокол обмена между представлением и бизнес логикой. Мне воот теперь вообще интересно посмотреть на вашу бизнес логику. Она у вас, скорее, выходит совершенно анемичной.
B>К примеру, у меня на View есть PersonWithName, в котором нет DOB, потому что он в SecuredPersonInfo.
B>В результате мне чтобы посчитать AGE нельзя просто взять Person.calcAge(), мне нужно дописать Age в PersonWithName, и в маппинге.
B>Я уже задал этот вопрос выше. Как вы переиспользуете логику бизнес-объектов в слоях, где у вас вместо бизнес-объектов лишь обрубки?

Отчего вы решили что вместо бизнес объектов у нас обрубки? "у меня на View есть PersonWithName" это вы про свой проект говорите, или иносказательно про мой?
Допустим про мой.. Итак есть бизнес объект PersonBO, и вьюшка PersonWithNameVO. Делаем в PersonBO метод вычисляющий возраст, и обзываем getAge(). Далее во вьюшке делаем свойство age. Все.
Маппер замапит возраст на вьюшку. Нужен будет этот ворзаст в какой нибудь PersonFullInfoVO — тоже делается свойство age, или наследуется от PersonWithNameVO, тут по ситуации.

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.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, 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 может помочь не во всех вопросах, тогда вместе с преобразованием в хранимые процедуры и триггера может утекать и бизнес логика.

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

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

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

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

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

Здравствуйте, 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 способ решать задачу на всех технологиях, причем способы различные? Я же предлагаю один унифицированный способ (раздаление на слои и использование маппера), которой будет подходить для всех технологий.

).
Были мысли сделать навороченно, с конфигурированием, приблизительно что в этой либе. Потом подумал, что смысла не будет. И поставил только цель как можно ближе языку и как можно меньше конфигурирования, чтоб был один метод — 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, Вы писали:

B>- монструозными вычислениями в Service с нарушением инкапсуляции (внутри классов та же логика выглядит, читается и поддерживается проще)
B>- необходимостью таскать за собой Service везде где вообще нужна логика — интерцеторы, GUI и пр.
Мне интересно как это вообще можно поддерживать. Ведь мне зачастую чтоб дернуть какой метод, нужно сделать это в контексте транзакции. А то и чтоб AOP обертка какая дергалась. Что, в Entity спрингом инжектить сервис чтоль? Я видел такое когда то в одном проекте — ужас! А логика то весьма может навороченная быть. И если метод вычисления возраста еще имеет смысл в сам класс Entity добавить, то метод рассчета каких нидь процентов по кредиту — это по любому внешний сервис, если ты не враг себе. Ибо для рассчета этих процентов возможно потребуется сделать запрос через 10 различных вебсервисов, чтоб это не тормозило, еще и кучу кеширования делать — это явно не в Entity пихать нужно. И сервис слой по любому будет.

B>Service это паттерн TransactionScript. Там живут бизнес транзакции. Вынос вообще всей логики из бизнес-объектов в Service приводит к трудно четаемому и слабо переиспользоваемому коду. И ещё к процедурному стилю.
Процедурный стиль это что то плохое? Лично я стили всегда мешаю, и пишу как в ООП, так и в функциональном и процедурном. А иногда и декларативном. Серебрянной пули нет. И во многих случаях как раз применение процедурного стиля — это как раз улучшение читаемости и повторной используемости.

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

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

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

GT>>А, давайте рассмотрим оба варианта.
Кажется вы забыли ответить

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

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

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

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

E>Мне интересно как это вообще можно поддерживать. Ведь мне зачастую чтоб дернуть какой метод, нужно сделать это в контексте транзакции.
Не хочу никого задеть. Но когда пишешь только Web проекты вида запрос-ответ, то оно кажется именно так. Когда тебе нужна одна и та же логика в нескольких слабо связаных звеньях приложения, то смотрится всё в ином свете. У меня сейчас GUI, Business Transaction, Cross-server Data Synchronization. Они друг с другом не пересекаются. 1й работает на клиенте, второй на сервере, третий на отдельном сервере. И всем нужно использовать одну и ту же бизнес-логику, которая просто вычисляется из свойсв бизнес-сущностей. Нафиг мне транзакция для вычисления состояния объекта?

E>А то и чтоб AOP обертка какая дергалась. Что, в Entity спрингом инжектить сервис чтоль? Я видел такое когда то в одном проекте — ужас! А логика то весьма может навороченная быть.
Что-то тебя понесло не в ту степь.

E>И если метод вычисления возраста еще имеет смысл в сам класс Entity добавить, то метод рассчета каких нидь процентов по кредиту — это по любому внешний сервис, если ты не враг себе. Ибо для рассчета этих процентов возможно потребуется сделать запрос через 10 различных вебсервисов, чтоб это не тормозило, еще и кучу кеширования делать — это явно не в Entity пихать нужно. И сервис слой по любому будет.
У меня масса методов, которые вычисляются по состоянию сущности. И в зависимости от состояния, тот или иной слой принимает решение. Никакие транзакции там не нужны.

E>Процедурный стиль это что то плохое? Лично я стили всегда мешаю, и пишу как в ООП, так и в функциональном и процедурном. А иногда и декларативном. Серебрянной пули нет. И во многих случаях как раз применение процедурного стиля — это как раз улучшение читаемости и повторной используемости.
Ты предлагаешь ВСЕ методы вынести из Entity в Service. И как у нас будет ООП в этом случае работать? Параллельно с иерархией сущностей будет аналогичная иерархия сервисов?

E>Я не очень понимаю необъодимость отдельных бинов для бизнес логики, отличных от ORM. Соответственно этого слоя не будет да и все. А во view, где не нужно ничего считать и требуется только отобразить, возраст можно предоставлять уже посчитанным.
Это не я придумал. Это в статье написано.

E>На вьюшку крайне желательно чтоб все попадало уже засинхронизированным
"Крайне желательно". А вычисление по текущему состоянию на View мне гарантирует что состояние всегда синхронизировано.

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

GT>Маппить поле на коллекцию, это как? Можете поподробнее, или лучше напишите кодом.
Ну, вот так. В Legacy системе есть поля Rate1, Rate2,... Rate16. В новой системе это коллекция.

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

freeBusyViewOptionsType.setMergedFreeBusyIntervalInMinutes(60);
freeBusyViewOptionsType.getRequestedView().add("Detailed");

Упс. Мне эти констаны нужны исключительно для маппинга на внешнюю модель. В моей модели они не используются вообще нигде.

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

GT>>>А, давайте рассмотрим оба варианта.
GT>Кажется вы забыли ответить

"Некада". Позже будет время, найду пример и покажу.

GT>Кстати я щас подумываю встроить в маппер функцию тестирования маппинга. Суть в следующем. Модель заполняется случайными данными, все его чайлдовые бины, коллекции, тоже заполнятся рекурсивно. Целевой объект пуст. Потом вызвается map, и после этого идет проверка чтобы все поля целевого объекта были замаплены. Таким образом можно написать юнит тест в котором просто вызвать данный метод.
Та ну на. Сделайте маппинг на лямбдах. Большего и не нужно.

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

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

GT>>Маппить поле на коллекцию, это как? Можете поподробнее, или лучше напишите кодом.
B>Ну, вот так. В Legacy системе есть поля Rate1, Rate2,... Rate16. В новой системе это коллекция.

Коллекция чего? Значений того же типа что и Rate1, Rate2,... Rate16? Можно подумать над тем чтобы добавить возможность такого маппинга, только есть
сомнения в том, что это понадобится очень часто. Но, приниципально не вижу проблемы научить маппер делать такое.

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

B>freeBusyViewOptionsType.setMergedFreeBusyIntervalInMinutes(60);
B>freeBusyViewOptionsType.getRequestedView().add("Detailed");
B>

B>Упс. Мне эти констаны нужны исключительно для маппинга на внешнюю модель. В моей модели они не используются вообще нигде.

Ну вы понимаете что маппер вам тут не помошник?

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

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

GT>>>>А, давайте рассмотрим оба варианта.
GT>>Кажется вы забыли ответить

B>"Некада". Позже будет время, найду пример и покажу.

GT>>Кстати я щас подумываю встроить в маппер функцию тестирования маппинга. Суть в следующем. Модель заполняется случайными данными, все его чайлдовые бины, коллекции, тоже заполнятся рекурсивно. Целевой объект пуст. Потом вызвается map, и после этого идет проверка чтобы все поля целевого объекта были замаплены. Таким образом можно написать юнит тест в котором просто вызвать данный метод.
B>Та ну на. Сделайте маппинг на лямбдах. Большего и не нужно.

С удовольствием, только расскажите как это

И еще, лябды ж буду только в java 8, а как быть проектам на java 6-7 ?

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

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

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

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

Если честно то не уверен что все технологии подрреживают конфигурацию без аннотаций. И хотел бы я посмотреть на все эти конфиги.. Как по мне то поддерживать их, это кромешный ужас. Во-первых, не наглядно. На вью объект глянул — и сразву видно что будет передаваться. А там какой то специфичнй для технологии конфиг.. В одной технологии однин конфиг, в другой — другой конфиг. Бред какой-то.

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

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

	От:	Blazkowicz
	Дата:	21.10.13 06:24
	Оценка:	9 (1)

	От:	GreenTea
	Дата:	27.10.13 12:21
	Оценка:	8 (1)

	От:	GreenTea
	Дата:	20.10.13 12:54
	Оценка:	4 (1)

	От:	Blazkowicz
	Дата:	28.10.13 07:10
	Оценка:	1 (1)

	От:	GreenTea
	Дата:	21.10.13 08:20
	Оценка:

	От:	elmal
	Дата:	22.10.13 07:19
	Оценка:

	От:	vsb
	Дата:	22.10.13 07:44
	Оценка:

	От:	hrensgory
	Дата:	22.10.13 07:49
	Оценка:

	От:	StanislavK
	Дата:	22.10.13 07:59
	Оценка: