Каковы преимущества и недостатки Ядра Фасада Сессии Шаблон J2EE?

Rod Johnson утверждает, что главная причина, Вы хотели бы использовать Фасад Сессии, состоит в том, если Вы делаете, контейнер справился с транзакциями - которые не необходимы с более современными платформами (как Spring.)

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

Счастливый услышать контрастирующие аргументы.

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

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

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

Принятие (b), что Вы имеете в виду общий архитектурный принцип фасада сессии - затем

Сервисы отделения и потребители и обеспечение дружественного интерфейса поверх этого являются хорошей идеей. Информатика решила много проблем путем 'добавления дополнительного слоя косвенности'.

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

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

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

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

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

Как правило, большинство Фасадов Сессии реализовано как сессия не сохраняющая состояние EJBs. Или если Вы находитесь на земле Spring с помощью AOP для транзакций, можно создать сервис POJO то, что может быть всеми точками соединения для менеджера транзакций.

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

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