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

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

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

Изменить: (попытка уточнить, поскольку никто не ответил на этот момент):

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

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

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

Изменить 2:

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

Изменить 3: Пожалуйста, см. Мой комментарий в ответ arjan.

Ответ 1

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

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

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

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

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

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