Предпосылка
Недавно я читал/смотрел много статей/видео от Java Champion Adam Bien, где он выступает за использование древнего, но обновленного Entity - Control - Boundary Design Pattern JAVA EE >= 6.
Используя возможности CDI, EJB 3.1, JPA 2 и других функций JAVA EE 6, эта модель должна помочь в создании более бизнес-ориентированных компонентов, упростить модульное тестирование и с более высоким разделением проблем, основанных на обязанностях.
Так как я использую все перечисленные выше функции, и этот шаблон звучит очень интересно, я изучаю его, чтобы увидеть, может ли ЕЦБ соответствовать моим следующим требованиям проекта.
Что у меня до сих пор
В ECB каждый логический объект разбивается на три части (пожалуйста, поправьте меня, если я ошибаюсь):
-
a Граница, своего рода мощный фасад, единственный класс, доступный извне. И для внешних (если я правильно понял), мы имеем в виду как вне приложения, например. удаленный клиент, И вне пакета компонентов, например. другая часть моего приложения;
-
a (n опционально) Контроллер, ответственный за какие-то операции (например, проверка сущности);
-
a Entity, который может быть чистым сущностью JPA, но также может содержать внутреннюю логику оформления/валидации/(минимальную).
Например, рассмотрим наличие двух разных сущностей (Orange и Apple), класс для выполнения CRUD на них (FruitsManager) и класс для выполнения некоторых элементов управления над ними (FruitsQualityChecker).
До вчерашнего дня это было бы что-то вроде OLD WAY):
com.foo.bar.business.FruitsService /* CRUD */ com.foo.bar.business.FruitsQualityChecker /* CONTROL */ com.foo.bar.model.Orange /* ENTITY */ com.foo.bar.model.Apple /* ENTITY */
в то время как с ECB я бы (NEW WAY):
com.foo.bar.business.oranges.boundary.Oranges /* CRUD */ com.foo.bar.business.oranges.control.QualityChecker /* CONTROL */ com.foo.bar.business.oranges.entity.Orange /* ENTITY */ com.foo.bar.business.apples.boundary.Apples /* CRUD */ com.foo.bar.business.apples.control.QualityChecker /* CONTROL */ com.foo.bar.business.apples.entity.Apple /* ENTITY */
Затем я могу CRUD и исследовать каждую сущность сингулярно, например. с
Oranges.findOrangesByPrice(min, max);
Основной вопрос
Как я должен обрабатывать кросс-компонентные исследования, например, findFruitsByPrice(min,max) ?
Должен ли я звонить как findOrangesByPrice, так и findApplesByPrice и суммировать результаты? Из какого класса упакован где?
И что, если у меня есть страница поиска со многими критериями, которая должна пересечь 50 объектов? Выполняя в 50 раз метод поиска каждого объекта, а затем выполните интерполяцию, звучит как очень уродливый способ с огромным воздействием на производительность. По-моему, мне все еще нужен центральный пункт, чтобы выполнять такие вещи. Должен ли он быть другим компонентом, называемым, например. Searches, что в его Границе называет другие границы? Этот момент неясен для меня ATM.
Боковой вопрос
Имеет ли смысл использовать ЕЦБ с основанной на действии структурой? Или этот шаблон отнесен к инфраструктурам на основе компонентов?
Я использую Struts2, это основанная на действии среда MVC, и я совершенно незнакома с JSF2 (стандарт JAVA EE 6 и используется в большинстве витрин Adam Bien), которая является основанной на MVC структурой;
Помимо дополнительного усилия по мышлению архитектуры "компонентный способ", есть ли что-то, препятствующее мне использовать ECB на уровне бизнес?
Поскольку большинство границ в примерах Адама Биена являются службами REST (как правило, это больше замена Struts2 Actions, чем "новая передача в цепочке" ), это заставляет меня сомневаться в том, что она вполне может быть пригодна для экосистемы Struts2.
Скажи свое. Пожалуйста.