Имеем следующее: Domain, DAO, SessionBeans (локальные). Клиент всего этого — веб-приложение. ORM — Hibernate. Так как активно используется Lazy-load то было принято решение нагородить DTO чтобы не заморачиваться с исключениями ленивой загрузки при закрытой сессии.
Все великолепно, но DTO надо собирать, вот только я не могу понять в чем прелесть Transfer Object Assembler?
Фаулер предлагает их со следующим интерфейсом — Assembler.writeDTO(SomeDomainObject obj) но по сути DTO может состоять не только из данных одного объекта домена а еще и из других кусков данных объектов предметной области которые могут быть и не связаны прямо с SomeDomainObject.
Например нужно выбрать категорию с товарами из каталога, учитывая как статус категории (ACTIVE, INACTIVE), так и статус товаров. Для этого сервис предусматривет операцию loadItems(String categoryId, Status status, int page, int size).
Что делает SessionBean — он обращается к CategoryDAO и выбирает активную категорию. Далее создает сборщик и передает объект категории сборщику, тот дергает ItemDAO выбирая необходимые товары, наполняет DTO. Для разных вариантов использования этой операции SessionBean'a придется писать разные классы сборщиков (один выбирает активные другой и те и другие или только неактивные товары и т д.). Конечно пример несколько идиотичен, но подобное возможно.
Не проще ли делать сборщики с методами принимающими параметры бизнес-операции (метода SessionBean'a) и тот уже дергает сервисы, DAO и домен. Тоесть вызываемый сервис просто делегирует работу соответствующему сборщику передав ему свои параметры. Assembler в этом случае выбрасывает те же Exception'ы что и сервис. Ну а в случае разных сценариев обновления уже никуда не денешся — писать разные сборщики. Если пойти еще дальше, то сборщики просто не нужны! Если DTO имеют вменяемые конструкторы то красивее будет просто создать объект переноса данных без нагромождения N классов, кол-во которых ИМХО прямо зависит от кол-ва бизнес-операций.
Сейчас глубокая ночь, прошу быть снисходительными если сильно сглупил
