@stateful и @sessionScoped - разница и когда использовать их правильно?

Question

Я читал разные статьи об использовании @Stateful и @SessionScoped аннотации и их отличия, включая this post. Из точки определения используется @sessionScoped, когда сеанс необходим/создан между уровнем клиент/web, а @Stateful необходим в слое бизнес-логики. Но я до сих пор не понимаю реальных различий, когда речь заходит о их реализации. Вот простой пример

@Named 
@SessionScoped 
ShoppingCartUIBean { 

@inject 
    shoppingCart cart; 
    // more code 
} 

@Stateful 
ShoppingCart { 

//business logic of adding/updating/deleting cart items 
} 

1. Как это Http сессия поддерживается @SessionScoped боба между заданным пользователем и сервером? То есть, если у меня есть корзина для покупок, открытая на разных компьютерах, я должен иметь возможность видеть мою корзину покупок, связанную с моим профилем пользователя. Как это установлено?
2. Что произойдет, если я переключу два annonations на вышеуказанные бобы? будет ли это иметь какой-либо эффект? (извините, это может звучать глупо. Я попадаю в мир Java EE, поэтому я хочу, чтобы основы были правильными).
3. Согласно этому замечательному сообщению на Differences : @SessionScoped vs @Stateful and @ApplicationScoped vs @Singleton, @Stateful beans вряд ли используются в веб-приложениях. Есть ли случай, когда @Stateful абсолютно необходим?
4. ON Соответствующая записка: легально ли вводить фасоль @stateful в @ApplicatonScoped bean? Это означало бы, что у всего приложения есть один бонус @stateful, и все клиенты используют один и тот же экземпляр одного компонента состояния через прокси. (Как показано здесь, не вводить @Stateful в servletsEJB example for stateless and stateful beans difference).

Спасибо.

Answer 1

Я постараюсь ответить на некоторые ваши вопросы своими силами.

Ad.1 @SessionScoped посвящен сеансу браузера, поэтому вы не увидите тот же сеанс на разных компьютерах (или в браузерах).

Ad.2 Вы не можете думать об этих двух как о тех же компонентах только из-за того же объема. Фундаментальная мысль состоит в том, что EJB и JSF beans полагаются на разные уровни архитектуры. Бобы EJB должны реализовывать бизнес-логику, тогда как jsf beans должны поддерживать формы и другие компоненты ui.

Ad.3 @Stateful beans очень полезны в каркасе шва. Использование этих компонентов и расширенный контекст устойчивости - это решение для ленивой ошибки инициализации (возможно, это причина, по которой создатели шва используют эти бобы). Я предпочитаю безфакторные бобы по производительности, но это вряд ли зависит от варианта использования (хотите ли вы сохранить состояние или нет).

Ad.4 В общем, вы не должны вводить фасоль «меньше видимости» в «более объемные» компоненты. Область приложения будет существовать, пока сеанс может быть уничтожен и что этот компонент приложения должен иметь вместо уничтоженного сеансового компонента?

Исправьте меня, если я ошибаюсь ни с одним из этих ответов.