(Entity-Control-Boundary pattern) → Как работать с двумя объектами?

Предпосылка

Недавно я читал/смотрел много статей/видео от 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.

Скажи свое. Пожалуйста.

Ответы

Ответ 1

Насколько я понимаю шаблон дизайна, вы правы с тем, что "вы получили до сих пор".

К вашему главному вопросу: как и в другом шаблоне проектирования, вы можете просто ввести еще один SuperComponent, который используется в некоторых конечных точках (или один, так что он не становится чрезвычайно большим). Этот SuperComponent будет делать все правильно: вы будете использовать некоторые существующие компоненты, если это необходимо, чтобы качество и качество кода не пострадали. Что я имею в виду здесь: вы, вероятно, напишете логику, относящуюся к этой конкретной конечной точке, которая не заботится о том, возвращает ли она Oranges AND Apples, делая один запрос к БД (если ваша модель домена может это сделать). Использование других компонентов для извлечения этих плодов и их объединение - плохой дизайн, независимо от того, какие шаблоны дизайна вы используете (изображение вы получите позже, а затем вам придется писать код/​​исправлять ошибки, чтобы получить поддержку для новые плоды).

Теперь как-то связано с вашим вопросом (IMHO): ЕЦБ в порядке для небольших проектов, но для больших проектов вам, вероятно, понадобится более слоистая структура:

  • веб-уровень, который просто обрабатывает запросы/ввод от пользователя (мне не нравится идея о том, что мои EJB знают о HttpRequest и HttpResponse s)

  • многоуровневая модель приложения с уровнем DAO (необязательно для операций CRUD, но для случая вы используете тот же NamedQuery с 5 параметрами в нескольких EJB).