当前位置: 首页 > 知识库问答 >
问题:

@有状态和@sessionScoped-差异以及何时正确使用它们?

南宫松
2023-03-14

我读过关于使用@Stateful@SessionScoped注释及其差异的不同文章,包括这篇文章。从定义上看,当客户端/web层之间需要/创建会话时,使用@sessionScoped,而在业务逻辑层中需要@Stateful。但是,在实施它们时,我仍然没有掌握真正的区别。下面是一个简单的例子

@Named
@SessionScoped
ShoppingCartUIBean {

 @inject 
  shoppingCart cart;
  // more code
}

@Stateful
ShoppingCart {

//business logic of adding/updating/deleting cart items
}
  1. @sessionscopebean如何维护给定用户和服务器之间的Http会话?也就是说,如果我在不同的计算机上打开了购物车,我应该能够看到我的购物车,它与我的用户配置文件相关联。这是如何建立的

谢谢。

共有1个答案

裴俊智
2023-03-14

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

Ad.1@SessionScoped是关于浏览器会话的,因此您不会在不同的计算机(或浏览器)上看到相同的会话。

Ad.2你不能仅仅因为同一个范围就把这两个组件看作是相同的组件。基本思想是EJB和JSFbean依赖于不同的体系结构层。EJB bean应该实现业务逻辑,而jsf bean应该维护表单和其他ui组件。

Ad.3@Stateful bean在seam框架中非常有用。使用这些bean和扩展持久性上下文是惰性初始化错误的解决方案(可能这就是seam创建者使用这些bean的原因)。根据性能,我更喜欢无状态bean,但它几乎不取决于用例(无论您是否希望保持状态)。

Ad.4一般来说,您不应该将“较小范围”的bean注入到“较大范围”的bean中。当会话可能被销毁时,应用程序作用域将存在,这个应用程序bean应该有什么来代替被销毁的会话bean?

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

 类似资料:
  • 我已经开始学习ReactJS,有一个关于无状态和有状态组件的问题。一般来说,我遵循组件和容器的分离,如下所示。有状态函数在组件文件夹中,其他逻辑操作在容器文件夹下。文件夹结构 让我们思考材料UI下拉列表。 为了打开和关闭下拉菜单和方法更改打开状态,这意味着它是有状态组件。但没有其他变化(省略年龄设置)。它似乎是可重用的组件,但包括状态与非常简单的操作,如打开和关闭。我应该放入哪个文件夹?容器还是组

  • 问题内容: 当前,我们将一个有状态的bean注入到Servlet中。问题在于,有时在有状态Bean上执行方法时会得到。 在上面的代码中,将检查是否需要打开到报表中指定的数据库的新连接,然后根据查询创建HTML中的报表,该查询是根据指定的参数构建的。 之所以选择在无状态Bean上使用有状态Bean,是因为我们需要打开与未知数据库的数据库连接并对其执行查询。对于无状态Bean,重复地打开和关闭与该Be

  • 我了解到CDI Beans可以在不同的基于Web应用程序的作用域中使用(只有在那里,对吗?)。例如:@quiestScoped、@SessionScoped等等。@SessionScoped在整个浏览器会话中保存托管bean中的数据。这在逻辑上听起来很安静,因为注释名称描述了它的功能。然而-现在我仔细查看了EJB会话bean。到目前为止,我知道这样一个人可能有三种状态之一:无国籍、有州和单身。对我

  • 我正在开发一个小待办事项应用程序,作为使用React的练习。我有一个这样的模拟服务: 在我的React应用程序中,我有一些包含TODO的状态: 是一个函数,我将它传递到我的组件中,当我想完成这样一个Todo时使用: 因此,每当用户单击复选框并使用调用时,就会从服务对象中删除它,并且状态应该更新,但最奇怪的事情发生了。 当调用时,todo将被正确删除,但当调用时,旧的todo仍然存在!如果我将内容写

  • 问题内容: 在Swift 2.0中 ,Apple引入了一种处理错误的新方法(do- try-catch)。几天前,在Beta 6中,甚至引入了一个更新的关键字()。另外,知道我可以使用。这3个关键字之间有什么区别,何时使用每个关键字? 问题答案: 已为Swift 5.1更新 假定以下抛出函数: 当您尝试调用可能抛出的函数时,有2个选项。 您可以通过将呼叫围绕在do-catch块中来承担 处理错误

  • 问题内容: 在大多数情况下,我将使用异常来检查代码中的条件,我想知道何时才是使用断言的适当时间? 例如, 您能指出断言如何适合这里吗?我应该使用断言吗? 似乎我从未在生产代码中使用断言,而仅在单元测试中看到断言。我确实知道,在大多数情况下,我可以像上面一样使用异常来进行检查,但是我想知道“专业”地执行异常的适当方法。 问题答案: 断言应用于检查不应发生的事情,而异常应用于检查可能发生的事情。 例如