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

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

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

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

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

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

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

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

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