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

Question

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

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

Справедливы ли эти предположения в конкретной среде?

Answer 1

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

В частности, с сессионным фасадом — вы используете сессионный EJB в качестве бизнес-фасада — и это хорошо, потому что тогда вы можете воспользоваться всеми службами J2EE (аутентификация/авторизация, транзакции и т. д.)...

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

Answer 2

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

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

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

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

Answer 3

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

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

Приятно услышать противоположные аргументы.

Answer 4

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

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

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

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

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

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

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

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

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