Каковы преимущества и недостатки шаблона Session Façade Core J2EE?

Question

Каковы преимущества и недостатки шаблона Session Façade Core J2EE?

Какие предположения стоят за этим?

Являются ли эти предположения действительными в конкретной среде?

Answer 1

Session Facade - это фантастический паттерн - это действительно специфическая версия паттерна Business Facade. Идея состоит в том, чтобы связать бизнес-функции в отдельные пакеты - такие как TransferMoney (), Withdraw (), Deposit () ... так, чтобы ваш код пользовательского интерфейса обращался к вещам с точки зрения бизнес-операций, а не к низкоуровневому доступу к данным или другим деталям. что это не должно беспокоить.

В частности, с помощью Session Facade - вы используете Session EJB в качестве бизнес-фасада - что приятно, тогда вы можете воспользоваться всеми услугами J2EE (аутентификация / авторизация, транзакции и т. Д.) ...

Надеюсь, это поможет ...

Answer 2

Кажется, что всякий раз, когда вы говорите о чем-либо, связанном с J2EE - всегда есть целая куча предположений за сценой - которые люди предполагают так или иначе - что затем приводит к путанице. (Я, наверное, тоже мог бы прояснить вопрос.)

Если (а) мы хотим использовать транзакции, управляемые контейнером, в строгом смысле через спецификацию EJB, то

Фасады сессий - хорошая идея, поскольку они абстрагируют низкоуровневые транзакции базы данных, чтобы обеспечить управление транзакциями приложений более высокого уровня.

Если предположить (б), что вы имеете в виду общую архитектурную концепцию фасада сеанса - тогда

Хорошей идеей является разделение услуг и потребителей и обеспечение дружественного интерфейса. Информатика решила много проблем, «добавив дополнительный слой косвенности».

Род Джонсон (Rod Johnson) пишет: «SLSB с удаленными интерфейсами обеспечивают очень хорошее решение для распределенных приложений, построенных на основе RMI. Однако это требование меньшинства. Опыт показывает, что мы не хотим использовать распределенную архитектуру, если этого не требуют требования. Мы по-прежнему можем обслуживать удаленных клиентов, если необходимо, внедряя удаленный фасад поверх хорошей совместно расположенной объектной модели ». (Джонсон, R "Разработка J2EE без EJB" стр. 119.)

Предполагая (c), что вы рассматриваете спецификацию EJB (и, в частности, компонент фасада сеанса) как упадок в ландшафте хорошего дизайна, тогда:

Род Джонсон пишет «В общем, не так много причин, по которым вы бы вообще использовали локальную SLSB в приложении Spring, поскольку Spring обеспечивает более способное декларативное управление транзакциями, чем EJB, а CMT обычно является основной мотивацией для использования локальных SLSB. Поэтому вам может не понадобиться Слой EJB вообще. "http://forum.springframework.org/showthread.php?t=18155

В среде, где производительность и масштабируемость веб-сервера являются главными проблемами - а стоимость является проблемой - тогда архитектура фасада сеанса выглядит менее привлекательной - проще общаться напрямую с базой данных (хотя это больше касается многоуровневое.)

Answer 3

Род Джонсон утверждает, что основной причиной, по которой вы хотите использовать Session Facade, является то, что вы выполняете транзакции, управляемые контейнером, - в которых нет необходимости в более современных средах (например, Spring).

Он говорит, что если у вас есть бизнес-логика - поместите это в POJO. (С чем я согласен - я думаю, что это более объектно-ориентированный подход, а не реализация сессионного EJB.) http://forum.springframework.org/showthread.php?t=18155

Рад слышать противоречивые аргументы.

Answer 4

Основным преимуществом шаблона Session Facade является то, что вы можете разделить приложение J2EE на логические группы по бизнес-функциям. Фасад сеанса будет вызываться POJO из пользовательского интерфейса (то есть бизнес-делегата) и иметь ссылки на соответствующие объекты доступа к данным. Например. PersonSessionFacade будет вызываться PersonBusinessDelegate, а затем он может вызывать PersonDAO. Методы PersonSessionFacade будут, по крайней мере, следовать шаблону CRUD (Создать, Получить, Обновить и Удалить).

Как правило, большинство фасадных сессий реализуются как EJB-компоненты сессий без сохранения состояния. Или, если вы находитесь в Spring land, используя AOP для транзакций, вы можете создать сервис POJO, который может быть всеми точками соединения для вашего менеджера транзакций.

Другое преимущество шаблона SessionFacade заключается в том, что любой разработчик J2EE с небольшим опытом сразу поймет вас.

Недостатки шаблона SessionFacade: он предполагает особую корпоративную архитектуру, которая ограничена пределами спецификации J2EE 1.4 (эти критические замечания см. В книгах Рода Джонсона). Наиболее разрушительным недостатком является то, что это сложнее, чем необходимо. В большинстве корпоративных веб приложений вам понадобится контейнер сервлетов, и большая часть нагрузки в веб-приложении будет на уровне, который обрабатывает запросы HttpReques или доступ к базе данных. Следовательно, не представляется целесообразным развертывать контейнер сервлета в отдельном пространстве процесса от контейнера EJB. То есть удаленные вызовы EJB создают больше боли, чем выгоды.