@stateful和@sessionScoped - 差异以及何时正确使用它们？

Question

我阅读了有关使用@Stateful和@SessionScoped发音及其差异的不同文章，包括this帖子。从定义点来看，在客户端/ Web层之间需要/创建会话时使用@sessionScoped，而在Bussiness Logic层中需要@Stateful。但在实施它们时，我仍然没有掌握真正的差异。这是一个简单的例子

@Named
@SessionScoped
ShoppingCartUIBean {

 @inject 
  shoppingCart cart;
  // more code
}

@Stateful
ShoppingCart {

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

1. 如何在给定用户和服务器之间由@SessionScoped bean维护Http会话？ 也就是说，如果我在不同的计算机上打开购物车，我应该能够看到与我的用户配置文件相关联的购物车。这是怎么建立的？
2. 如果我在上面的bean上切换两个annonations会怎样？会有什么影响吗？ （对不起，这可能听起来很愚蠢。我正在进入Java EE世界，所以我想让基础知识正确）。
3. 根据Differences : @SessionScoped vs @Stateful and @ApplicationScoped vs @Singleton上的这篇精彩帖子，@ Stateful bean几乎不用于Web应用程序。是否有@Stateful绝对必要的情况？
4. 相关说明：将@stateful bean注入@ApplicatonScoped bean是否合法？这意味着整个应用程序只有一个@stateful bean，并且所有客户端都通过代理使用一个有状态bean的相同实例。 （正如此处所示，不要在@Stateful EJB example for stateless and stateful beans difference中注入servlets。

感谢。

Answer 1

我会尽力回答你的一些问题。

Ad.1 @SessionScoped与浏览器会话有关，因此您不会在不同的计算机（或浏览器）上看到相同的会话。

Ad.2您不能仅仅因为相同的范围而将这两个视为相同的组件。基本思想是EJB和JSF bean依赖于不同的架构层。 EJB bean应该实现业务逻辑，而jsf bean应该维护表单和其他ui组件。

Ad.3 @Stateful bean在seam框架中非常有用。使用那些bean和扩展持久性上下文是延迟初始化错误的解决方案（可能这就是为什么seam创建者使用这些bean的原因）。我根据性能更喜欢无状态豆，但它几乎不取决于用例（无论你是否想要保持状态）。

Ad.4一般情况下，你不应该向“更多范围”的bean注入“less scope”bean。在会话可能被销毁时应用程序范围将存在以及此应用程序bean应该具有什么来代替销毁的会话bean？

如果我对这些答案有任何错误，请纠正我。