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

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