Почему при использовании сессионных компонентов фасада мы все еще должны использовать сессионные компоненты?

Question

При использовании шаблона проектирования фасада для структурирования бизнес-уровня EJB приложения, почему мы все еще должны использовать сессионные компоненты для реальной бизнес-логики? Есть ли конкретная причина не просто использовать простые классы Java (если не требуется управляемое внедрение контейнера)? Как производительность простого Java-класса по сравнению с сессионным EJB-компонентом не улучшит производительность в обход EJB-компонентов?

Просто суммируем два варианта:

<Ол>

КЛИЕНТ - > ФАСАД - > Сеанс бин

КЛИЕНТ - > ФАСАД - > РЕГУЛЯРНЫЙ КЛАСС JAVA

Зачем использовать 1 вместо 2?

Answer 1

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

В противном случае мои предпочтения всегда были бы вариантом 2, просто было бы меньше дерьма потреблять процессорное время, ошибаться и т. д.