Какой смысл использовать @Scoped с EJB?

Question

Обычно я использую @RequestScoped или @SessionScoped (из javax.enterprise.context), чтобы вводить объекты (например, в фасках лица), используя @Inject. Я также использую EJB. Как я понял, набор EJB-копий без сохранения состояния (пул) используется для инъекции в объекты. Причина в том, что существует много копий, заключается в том, чтобы обеспечить одновременный доступ к одному экземпляру EJB. Говоря о полных EJB-компонентах (опять же, как я понял), один из них связан с конкретной точкой внедрения. И они вводятся с помощью @EJB (тоже без состояния).

Часто в Интернете можно увидеть примеры использования @Stateless или @Stateful в сочетании с @Scoped. В чем их смысл?

Редактировать: (пытается уточнить, поскольку никто не ответил на этот момент):

Меня особенно интересует, меняются ли такие аннотации в какой-либо области (и если они - как) в момент создания экземпляра EJB. Для моего понимания: если у меня есть @EJB аннотированное поле, туда вводится объект соответствующего класса. Если такой EJB не имеет состояния, контейнер просто берет бесплатный экземпляр из пула предварительно созданных экземпляров. Размер пула можно изменить при необходимости. Он не имеет состояния, потому что не гарантируется сохранение объекта при вызовах методов нашего класса (то есть, класса, в котором есть поле, содержащее ссылку на EJB).

Мы также можем использовать EJB с сохранением состояния, и в этом случае один экземпляр сохраняется во время вызовов метода. Как я думаю, он будет просто введен один раз за создание объекта. (Существует также одноэлементный EJB, который используется всеми объектами).

Я не могу найти назначение аннотаций @Scoped для EJB здесь.

Редактировать 2:

Можно использовать такую ​​комбинацию аннотаций, если класс вводится через механизмы EJB и DI (@Inject). Это скорее, однако, особый случай и не элегантный. Я спрашиваю, знаете ли вы какие-либо другие причины.

Редактировать 3: Пожалуйста, смотрите мой комментарий под ответом Арджана.

Answer 1

Бин @Stateless или @Singleton может быть явно ограничен для предотвращения автоматического изменения его области действия на область, которая может быть недопустимой.Например, оба этих типа бинов не могут быть @RequestScoped.Посмотрите эту ссылку для получения дополнительной информации: http://docs.jboss.org/resteasy/docs/2.0.0.GA/userguide/html/CDI.html

@ Stateful имеет большой смысл (явно) ограничивать.А именно, без области видимости вы, как программист, должны позаботиться о вызове аннотированного метода @Remove.Это может быть проблематично с гарантией, так как такой bean-компонент обычно не используется ни в одном методе, где вы можете вызвать метод @Remove в блоке finally.С областью действия бин точно удаляется по окончании области действия.

Кроме того, без области действия вы не всегда можете использовать инъекцию для получения ссылки на заглушку бина с состоянием.А именно, каждый раз, когда происходит инъекция, вы получаете новый экземпляр.Это особенно проблематично при внедрении bean-компонента с состоянием в резервный EJB-компонент с областью запросов (JSF), где у вас есть намерение сохранить bean-компонент с состоянием в нескольких запросах.

Затем, в сочетании с @Named, вытакже можно использовать сессионный компонент напрямую в качестве вспомогательного компонента для выравнивания уровней приложения (см., например, http://jaxenter.com/java-ee-6-overview-35987-2.html).. Очевидно, что в этом случае вам нужна явная область действия. Теперь выравнивание слоев может быть не лучшим решением в больших приложениях, нодля небольших приложений и / или людей, только начинающих работать с Java EE, определенно желательно поместить бизнес-логику непосредственно в компонент поддержки, а затем требуется, чтобы компоненты поддержки имели доступ к сервисам (в основном транзакциям) того же типа, что и бизнес-компонентыобычно имеют.

Наконец, Гэвин Кинг (ведущий спецификатор CDI) предложил всегда использовать @Inject вместо @EJB. Единственное исключение касается удаленных EJB, где @EJB все еще используется.

Часть путаницы вокруг EJB и CDI заключается в том, что CDЯ - новая компонентная модель в Java EE и все еще относительно новая.Хотя они довольно хорошо интегрируются друг с другом, они по-прежнему являются двумя различными компонентными моделями, и еще не все лучшие практики были продуманы.Реза Рахман (член EG, автор книг EJB и автор CanDI по внедрению CDI) предположил, что модель EJB в будущем может быть модифицирована как набор служб CDI.Действительно, в Java EE 7 делается шаг, отделяя транзакционные сервисы от EJB и делая их доступными через (CDI) аннотации.