将原型范围与 Spring 一起用于服务外观和层

发布于 2024-11-30 05:29:56 字数 401 浏览 1 评论 0原文

我想更好地了解如何以及何时在 Spring 中使用原型范围才有意义。似乎与 EJB 世界中处理无状态会话 Bean 的方式类似(尽管 EJB 容器会从将要创建的无状态会话 Bean 池中释放一个实例,而不是按需创建新实例)。

我对此有几个基本问​​题:

1)从体系结构的角度来看,什么时候在典型的 J2EE Web 应用程序(Spring MVC/Hibernate 或 JDBC 模板数据库访问)中使用原型范围的 bean 有意义?

2) 是否有创建此类原型实例池的概念,类似于 EJB 服务器对无状态会话 bean 进行的池操作?

3) 是否应该使用原型范围创建服务外观(类似于 EJB 中的会话外观),这是否有助于处理来自 Web 层的并发请求?如何控制创建的实例数量(限制在某个可管理的数量,最好将它们池化)?

I wanted to understand better how and when it makes sense to use the prototype scope in Spring. Seems that it is similar how the stateless session beans have been handled in the EJB world (although, the EJB container would release an instance from a pool of stateless session beans that would be created rather than creating a new instance on demand).

I have a few basic questions about that:

1) From an architecture standpoint, when does it make sense to use prototype-scoped beans in a typical J2EE web application (Spring MVC/Hibernate or JDBC template DB access)?

2) Is there a concept of creating a pool of such prototype instances similar to the pooling that the EJB server would do with the stateless session beans?

3) Should the service facade (that is similar to the Session Facade in EJB) be created with a prototype scope and would that help in dealing with the concurrent requests coming from a web tier? And how do I control the number of instances that are created (limit to certain manageable number and, preferably, pool them)?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

独自唱情﹋歌 2024-12-07 05:29:56

假设您的服务是无状态的,您需要单例服务。这样,每个服务只有一个实例,并且由于它们是无状态的,因此它们是线程安全的。

您可能需要诸如请求操作之类的原型(例如在 struts 中),因此会创建一个新对象来处理每个请求。这些原型可以连接到单例服务。

来自文档

bean 部署的非单例、原型范围导致
每次请求特定的 bean 时都会创建一个新的 bean 实例
豆子做好了。也就是说,这个bean被注入到另一个bean或者你
通过容器上的 getBean() 方法调用来请求它。作为一个
规则,对所有有状态 bean 和单例使用原型范围
无状态 bean 的范围。

you would want singletons for services, assuming your services are stateless. That way you only have one instance of each service, and since they are stateless they are threadsafe.

you would want prototypes for things like request actions (e.g. in struts), so a new object gets created to handle each request. Those prototypes can be wired up to singleton services.

from the documentation:

The non-singleton, prototype scope of bean deployment results in the
creation of a new bean instance every time a request for that specific
bean is made. That is, the bean is injected into another bean or you
request it through a getBean() method call on the container. As a
rule, use the prototype scope for all stateful beans and the singleton
scope for stateless beans.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文