Фасад / Сервисная архитектура
Прежде чем задать свой вопрос, я должен описать, как создаются наши приложения.
Мы запускаем несколько веб-приложений, которые используют ejb на уровне сервиса. Я пытаюсь описать общение с помощью короткого примера:
- Бин JSF (PersonHandler) вызывает фасад для удаления объекта "Person"
- Фасад может использовать много разных услуг, но НЕ МОЖЕТ использовать другие фасады. В этом случае PersonFacade использует PersonService (для удаления человека) и NotificationService (для отправки электронного письма). Также транзакции контролируются логикой фасада. Электронные письма следует отправлять только в случае успешного совершения транзакции.
- Служба НЕ МОЖЕТ иметь ссылку на другую услугу или фасад. Вместо этого PersonService имеет только ссылку на PersonDao (постоянная логика).
Я думаю, что эта архитектура довольно распространена. Вот мой вопрос.
В методе удаления PersonFacade у нас есть действительно важный код, который мы не будем дублировать. Каждый раз, когда человек должен быть удален, этот кусок кода должен работать. В другой логике фасада нам нужен точно такой же код, но связь фасада <-> фасада не допускается.
Как лучше всего решить эту проблему?
Вот мое текущее решение, но я не доволен им. Я создал новый модуль ejb с ejb, который обрабатывает логику удаления. Оба фасадных модуля имеют зависимости от нового модуля, поэтому все работает, и я не нарушаю контракт "фасады никогда не используют другие фасады". Если мы будем использовать это каждый раз, когда нам понадобится один и тот же код в разных местах, наши модули взорвутся, и модули станут запутанными. На данный момент у нас более 250 модулей ejb/jar.
1 ответ
Ниже приведены два варианта, которые я бы рассмотрел.
- Иметь общую логику в базовом фасаде, от которого будут вытягиваться все фасады, или
- Переместите общую логику в вспомогательный класс (утилиту), который может вызывать любой фасад. Я вижу, вы уже делаете подобное, создавая новый ejb. Я не уверен, должен ли это быть ejb, зависит от точной логики.