我对这个话题有些怀疑。在我们对大多数 Spring bean（dao`s、服务和控制器）的应用程序中，我们使用“请求”范围。这种方法允许我们减少内存使用并创建无状态层。但另一方面，我们在 Spring 上下文初始化的每个请求上都失去了性能。我考虑在“单例”或“原型”范围内创建一些 bean，例如 DAO 层。
您在应用程序中使用了哪些技术？也许存在一些设计 Spring Web 应用程序 bean 范围的建议？
问问题
8821 次
2 回答
15
我在决定时倾向于使用的一般规则如下：
长寿状态
这是需要在多个请求 (http) 上保留状态的时候。在这种情况下，存储在会话范围内是有意义的。
短暂的状态
当您需要为任何给定请求保留状态时。也许您正在为表单实现类似支持 bean 的东西。在这种情况下，我使用请求范围。
无状态
这是单例，默认情况下从 spring 生成。除非我对状态有特定要求，否则这是我通常对所有 bean 都坚持的选项。当然它的性能也更高，因为 bean 只创建一次并被所有人使用。
在您的情况下，您的 DAO 和服务应该是无状态的（如果它们没有重新考虑您如何实现它们），因此应该是单例的。控制器应该再次是单例的，但是您的问题是它们是否包含状态？. 我不会太担心内存消耗，记住万恶之源是过早优化。坚持最佳实践，如果这不起作用，请修复它。
于 2013-02-28T21:05:27.060 回答
5
Singleton：将单个 bean 定义限定为每个 Spring IoC 容器的单个对象实例。
Prototype：将单个 bean 定义限定为任意数量的对象实例。
Request：将单个 bean 定义限定为单个 HTTP 请求的生命周期；也就是说，每个 HTTP 请求都将有自己的 bean 实例，该实例是在单个 bean 定义的后面创建的。仅在 Web 感知 Spring ApplicationContext 的上下文中有效。
Session：将单个 bean 定义限定为 HTTP Session 的生命周期。仅在 Web 感知 Spring ApplicationContext 的上下文中有效。
全局会话：将单个 bean 定义限定为全局 HTTP 会话的生命周期。通常仅在 Portlet 上下文中使用时才有效。仅在 Web 感知 Spring ApplicationContext 的上下文中有效。
除了这些信息，您应该将您的 DAO 标记为@Repository，将您的控制器标记为@Controller ，将您的服务层标记为@Service。
于 2013-02-28T22:17:03.573 回答