2016-10-13 5 views
1

Я узнал, что CDI Beans можно использовать в разных областях веб-приложений (только там, справа?). Например: @RequestScoped, @SessionScoped и так далее. @SessionScoped хранят данные в управляемом компоненте в течение всего сеанса браузера. Это звучит спокойно логически, потому что имя аннотации описывает, что он делает. Однако - теперь я ближе посмотрел на сессионные компоненты EJB. До сих пор я знаю, что такое может иметь одно из трех состояний: @Stateless, @Stateful и @Singleton. Для меня, похоже, существует прямая сопоставимость между этими и аннотациями бина CDI: @RequestScoped -> @Stateless, @SessionScoped -> @Stateful, @ApplicationScoped -> @Singleton. Но так как я изучал некоторые примеры, я нашел компонент, который включает в себя как @Stateful, так и аннотацию @SessionScoped. Я искал объяснения - но я не нашел ответа, который был бы понятен. Итак, что же такое разница? Почему я должен использовать обе аннотации? Спасибо.Diff между @SessionScoped (CDI) и @Stateful (Java EE)

+0

В первую очередь: CDI '@ SessionScoped' привязан к текущему сеансу HTTP; '@ Stateful' не распознает сеанс HTTP, скорее, он просто остается в пуле без учета состояния сеанса клиента. Там другие различия на основе использования, но это основное отличие – kolossus

ответ

0

EJB Beans по умолчанию давая вам Сделки, CDI Beans.

Я думаю, что разница

+0

Оба компонента CDI и EJB beans - управляемые компоненты. Они разделяют много базовых вещей, и правильно, что компонент EJB поддерживает транзакцию. Но это не может быть единственной разницей, иначе было бы бессмысленно использовать оба «@Stateful» и «@SessionScoped». ;) – CodeCannibal

0

CDI Бобы могут быть использованы в различных областях веб-приложений на основе (только там, правда?).

Неправильно. Бин CDI можно использовать в любом месте, которое вам нужно - соединение с DB/связь, логика бизнеса, программирование на основе событий даже в Java SE (Weld, эталонная реализация CDI, предлагает это и сейчас). Тем не менее, в частности, @SessionScoped bean более полезны в HTTP-сеансах, чем где-либо еще. Но все же вы можете представить (и использовать) сеанс как заданный период времени с отмеченным началом и концом. И в этих пределах сеанс существует - не обязательно быть сеансом HTTP, но он является наиболее очевидным.

прямая сопоставимость между теми и аннотациями в КДИ боба: @RequestScoped -> @Stateless, @SessionScoped -> @Stateful, @ApplicationScoped -> @Singleton.

Неправильно снова. EJB связаны только с веб-связью, CDI - нет. Также на основе выбранной вами аннотации вы также выбираете контейнер (CDI/EJB), который возьмет на себя ответственность за этот компонент. CDI объединяет все компоненты EJB (создавая прокси и делая его «по-видимому» компонентом CDI - позволяя вам использовать CDI в компоненте EJB).

Теперь, например, @Stateless в CDi/Weld внутренне представлена ​​в виде @Dependent объема, а не потому, что @RequestScoped@Stateless бобы в EJB являются повторно используемый и вы не можете на самом деле о том, что их состояние. В то время как с @RequestScoped в CDI вы активируете контекст запроса (давайте придерживаться HTTP, поэтому отправляем что-то, что вы его активируете), который вызывает создание всего @RequestScoped beans. После запроса все эти бобы уничтожены, никогда не использовались снова. Таким образом, вы можете полностью полагаться на то, что вы вкладываете внутрь, и вы также можете быть уверены, что он не будет жить после запроса.

Другая история - @ApplicationScoped по сравнению с @Singleton. Они действительно очень похожи, и наиболее важной деталью, вероятно, будет тот факт, что CDI создает свои собственные прокси-серверы из bean-компонентов. Но это было бы слишком подробно для этого вопроса, я думаю, вы теперь можете считать их сопоставимыми.

Diff между @SessionScoped (CDI) и @Stateful (Java EE)

Теперь, наконец, к первоначальному вопросу. Я думаю, чтобы понять эти различия в целом, вам нужно понять, что CDI работает на контекстах. Он всегда активирует контекст (контекст сеанса в этом случае), и в этот момент появляется набор из @SessionScoped beans, и вы можете общаться с ними, и у них есть значения и состояния и т. Д. Контексты взаимосвязаны, поэтому в то же время может существовать контекст запроса и контекст приложения действительно существует. Таким образом, мы можем сказать, что @SessionScoped привязан к сеансу и контролируется контейнером, а @Stateful предлагает сеанс, управляемый пользователями, с его жизненным циклом, управляемым клиентом, а также добавляет к нему множество других функций.

Причина, по которой вы можете иногда видеть обе аннотации в одном компоненте, заключается в том, что люди объединяют их, чтобы получить лучшее из обоих миров - жизненный цикл, управляемый контейнером, и добавленные функции. Но обратите внимание, что в то время как @Stateful не используется много в наши дни (обычно имеет смысл отказаться от @Stateless), @SessionScope гораздо более универсален и подходит практически к любому сценарию на основе сеанса.

Надеюсь, что он пролит хотя бы некоторый свет, это очень сложная тема, которую я боюсь.

Смежные вопросы