Фасадная/сервисная архитектура

Прежде чем я задам свой вопрос, я должен описать, как создаются наши приложения.

Мы запускаем несколько веб-приложений, которые используют ejb на сервисном уровне. Я пытаюсь описать общение на коротком примере:

  • Компонент JSF (PersonHandler) вызывает фасад для удаления объекта «Person».
  • Фасад может использовать множество различных сервисов, но НЕ МОЖЕТ использовать другие фасады. В этом случае PersonFacade использует PersonService (для удаления человека) и NotificationService (для отправки электронного письма). Также транзакции контролируются фасадной логикой. Электронные письма должны быть отправлены только в том случае, если транзакция успешно зафиксирована.
  • Служба НЕ МОЖЕТ иметь ссылку на другую службу или фасад. Вместо этого PersonService имеет только ссылку на PersonDao (логика сохранения).

Я думаю, что эта архитектура довольно распространена. Вот мой вопрос.

В методе удаления PersonFacade у нас есть действительно важный код, который мы не будем дублировать. Каждый раз, когда человек должен быть удален, этот фрагмент кода должен запускаться. В другой логике фасада нам нужен точно такой же код, но связь фасада ‹--> фасада не разрешена.

Какое лучшее решение этой проблемы?

Вот мое текущее решение, но я им не доволен. Я создал новый модуль ejb с ejb, который обрабатывает логику удаления. Оба фасадных модуля имеют зависимости от нового модуля, поэтому все работает, и я не нарушаю контракт «фасады никогда не используют другие фасады». Если мы будем использовать это каждый раз, когда нам нужен один и тот же код в разных местах, наши модули взорвутся, и модули станут запутанными. На данный момент у нас более 250 модулей ejb/jar.


person Community    schedule 19.03.2013    source источник


Ответы (1)


Ниже приведены два варианта, которые я бы рассмотрел.

  1. Иметь общую логику в базовом фасаде, от которого будут простираться все фасады, или
  2. Переместите общую логику во вспомогательный класс (утилиту), который может вызывать любой фасад. Я вижу, вы уже делаете нечто подобное, создавая новый ejb. Я не уверен, что это должен быть ejb, зависит от точной логики.
person techuser soma    schedule 19.03.2013