Здравствуйте, 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. И в нем выполнить логику. То мы в нем получаем бин одного типа (база данных). Копируем в бин другого типа (бизнес логика). Вы полняем логику. Конвертируем обратно. Так?