DAO 通常应具有哪些范围
毫无疑问，dao 不会拥有任何状态。
然而，为了最简单地访问该类，使用原型（=每次都是new）还是单例更好？
简单的对象创建对于 dao 来说是便宜的..它通常只包含一个 sessionfactory， 从单例列表访问对象可能同样昂贵。
澄清：这个问题的焦点是，DAO 的范围是否有一个共同的约定。
its out of question that a dao will not hold any state.
however, for easiest access to the class, is it better to use prototype( = new every time) or singleton?
simple object creation is cheap for dao's.. it typically only holds a sessionfactory,
accessing the object from a list of singletons may be equally expensive.
clarfication: the focus of this question is, if there is a common convention to the scoping of daos.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您的问题与架构有关，我会将 DAO 的范围限定为您正在执行的工作单元或事务。 这减少跨事务污染和线程问题的可能性。
如果您的问题是关于性能，那么答案就在分析器中，它为您的特定工作负载提供准确数字强>。
If your question is about architecture, I'd go with scoping DAOs to the Unit of Work or Transaction you are doing. This reduces the potential for cross-transaction pollution and threading-issues.
If your question is about performance, then the answer lies within a profiler, which gives you accurate numbers for your particular workload.
或者将原型与池结合使用，如下所述：
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/aop-api.html#aop-ts-pool< /a>
或此处：
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/classic-aop-spring.html#classic-aop-ts- pool
编辑：显然，我假设这里使用了 spring 。 否则我道歉
Or use prototype in combination with a pool as described here:
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/aop-api.html#aop-ts-pool
OR here:
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/classic-aop-spring.html#classic-aop-ts-pool
EDIT: obviously, I assume that spring is used here. Otherwise I apologize
我得出的结论是，不存在“完美”的决定方法。 单例范围很可能是在 Web 应用程序中执行此操作的错误方法，因为您将有不同的会话 - 每个请求一个。 因此，在 web 应用程序中，请求范围可能是正确的答案，但前提是您仅在请求中而不是在后台任务中使用它。 原型范围是可行的 - 但前提是您不在那里保存复杂的数据。
i have come to the conclusion that there is no "perfect" way of deciding this. singleton scope is most likely the wrong way of doing it in a web app, since you will have different sessions - one per request. so in a webapp - request scope may be the correct answer, but only if you are using it exclusively in requests and not in background tasks. prototype scope is viable - but only if you are not holding complex data there.