Я хотел бы знать, каковы основные различия между:
Я знаю, что @SessionScoped и @Stateful позволяют создавать новый экземпляр для каждого клиента. Я также знаю, что для @ApplicationScoped и @Singleton/@Stateless они распределяются между клиентами.
= > Но , когда следует рассмотреть, лучше выбрать EJB или другой?
@SessionScoped обозначает область видимости, а @Stateful - это то, что мы теперь будем называть стереотипом. @Stateful добавляет число услуг к bean, среди которых поведение транзакций и пассивация.
Центральным элементом @Stateful является, однако, его поведение в сеансе, которое действительно перекрывается с областью сеанса.
Разница заключается в том, что область сеанса привязана к сеансу HTTP, а @Stateful - это сеанс с открытым доступом, управляемый пользователем, который имеет ссылку на прокси-сервер bean.
@Stateful удаленный beans, где первоначально часть счетчика бит (RMI) сервлета. Где Servlets прослушивали удаленные HTTP-запросы из браузера, @Stateful remote beans прослушивал удаленные запросы RMI от апплетов (и более поздних клиентов Swing).
К сожалению, между ними было много несоответствий. Сервлет был только прослушивателем HTTP, а @Stateful beans автоматически включал в себя множество других функций. Сервлет также поделился сеансом со всеми другими сервлетами, а также разделил пространство имен компонентов Java EE со всеми другими сервлетами в войне, а с @Stateful EJB каждый отдельный bean имеет свое собственное пространство имен и компонентов.
С введением локального beans в EJB 2 и резким снижением клиентов Swing/Applet для удаленной связи EJB функция сеанса, поддерживаемая для @Stateful bean, стала менее понятной.
Я считаю справедливым сказать, что @Stateful просто не используется так много в наши дни. Для веб-приложения сеанс HTTP почти всегда ведет, что означает использование области сеанса и локального @Stateless beans и/или CDI beans для бизнес-логики.
В некоторых случаях @Stateful beans необходимы для их естественной поддержки расширенного контекста персистентности из JPA и для их характеристик пассивации (Servlet не имеет стандартизованного механизма пассивации). Обратите внимание, что @Stateful и @SessionScoped (или многие другие области) могут быть объединены. Преимущество их комбинирования заключается в том, что пользователю больше не требуется управлять временем жизни, но контейнер управляет этим.
Там есть несколько схожий рассказ для @ApplicationScoped и @Singleton, хотя без наследия (@Singleton - довольно новая вещь). @ApplicationScoped - это просто область, а @Singleton - это тип bean (если вы хотите, стереотип), который не только дает вам поведение приложения, но также предоставляет вам транзакционное поведение снова с автоматической блокировкой (которая может быть настроен через @Lock) и с нетерпеливым поведением конструкции (через @Startup).
Хотя @Stateful и @Singleton сами по себе довольно удобны, нынешний путь вперед в Java EE, по-видимому, заключается в том, чтобы разложить эти встроенные стереотипы на отдельно используемые аннотации и кто знает, возможно, однажды они станут реальными CDI стереотипы, состоящие из разложенных аннотаций.