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