我对这个话题有些怀疑。 在我们的大多数Spring bean（dao`s，服务和控制器）的应用程序中，我们使用“请求”范围。这种方法允许我们减少内存使用并创建无状态层。但另一方面，我们在Spring上下文初始化的每个请求上都松散了性能。 我想创造一些豆类，例如DAO层，在“单例”或“原型”范围内。
您在应用程序中使用了哪些技巧？ 也许存在一些设计Spring Web应用程序bean范围的建议？
答案 0 :(得分：15)
决定时我倾向于使用的一般规则如下：
长期居住状态
这是需要在多个请求（http）上保留状态的时间。在这种情况下，存储在会话范围内是有意义的。
短暂状态
当您需要为任何给定请求保持状态时。也许你正在为表单实现类似支持bean的东西。在这种情况下，我使用请求范围。
无状态
这是单身人士，默认情况下是从春天生成的。除非我对状态有特定要求，否则我通常会坚持使用所有bean。当然它也更高效，因为bean只创建一次并被所有人使用。
在你的情况下，你的DAO＆amp;服务应该是无国籍的（如果他们不重新考虑你如何实现它们），因此应该是单身人士。控制器应该再次单独使用，但问题是它们是否包含状态？。我不会太担心内存消耗，记住所有邪恶的根源是过早优化。坚持使用最佳实践，如果不起作用则修复它。
答案 1 :(得分：5)
Singleton ：根据Spring IoC容器将单个bean定义范围限定为单个对象实例。
原型：将单个bean定义范围限定为任意数量的对象实例。
请求：将单个bean定义范围限定为单个HTTP请求的生命周期;也就是说，每个HTTP请求都有自己的bean实例，它是在单个bean定义的后面创建的。仅在Web感知Spring ApplicationContext的上下文中有效。
会话：将单个bean定义范围限定为HTTP会话的生命周期。仅在Web感知Spring ApplicationContext的上下文中有效。
全局会话：将单个bean定义范围限定为全局HTTP会话的生命周期。通常仅在portlet上下文中使用时有效。仅在Web感知Spring ApplicationContext的上下文中有效。
除了这些信息之外，您还应将DAO标记为 @Repository ，将控制器标记为 @Controller ，将服务层标记为 @Service 。