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