.net NHibernate会话的生命周期应该是多少？

我是NHibernate的新手，在提前结束会议时遇到了一些问题。我通过重用会话而不是在每个事务中打开会话，暂时解决了这个问题。然而，我的印象是，每次需要时打开会话是会话生命周期管理的推荐方法。没有

所以,；建议以什么方式处理会话？他们的一生应该是什么？一次会议公关交易？一个单独的会话来处理一切？还是什么

编辑：

---

请注意，我的应用程序架构是一个与服务器端服务通信的桌面应用程序，这是使用NHibernate+Fluent处理所有数据库的功能。（如果这有任何区别…

会话应与工作单元相对应。当您使用该会话处理检索或持久化的对象时，会话应该保持活动状态。

没有一个答案适用于所有情况。的第13课时对该问题进行了很好的概述。

NHibernate框架和Microsoft ADO.NET实体框架的大部分内容类似。这是一篇关于如何在ADO.NET EF中控制ObjectContext生命线的非常好的文章

---

它也应适用于NHibernate会话。

在web应用程序中，每个请求应有一个会话。这使您能够完全控制会话生存期，并简化错误处理

在桌面应用程序中，我建议每个演示者使用一个会话（或表单，如果您愿意）。引用Ayende的话：

桌面应用程序的推荐做法 应用程序将使用每个会话的会话 表单，以便在 应用程序有自己的会话。每个 形式通常代表一种不同的形式 用户想要的工作 要执行，请匹配会话 终生工作 在实践中相当不错。增加 好处是你不再有 内存泄漏问题，因为 在中关闭窗体时 应用程序中，您还可以处置 一场这将使所有的 已由加载的实体 符合填海条件的时段 垃圾收集器（GC）

还有其他原因 每个表单更喜欢一次会话。 你可以利用NHibernate的 更改跟踪，以便刷新所有 更改数据库时 提交事务。它也 在两者之间创建隔离屏障 不同的表单，因此您可以提交 对单个实体所做的更改 担心其他方面的变化 显示在其他屏幕上的实体 表格

---

您需要一种会话管理策略，使您的应用程序能够有效运行，并充分利用NHibernate为您提供的功能—最显著的是缓存和延迟加载

创建会话是一个廉价的过程，只需要很少的前端RAM或CPU，因此您不必担心保存或重用会话（事实上，重用会话可能会导致一些不愉快的、未预料到的副作用）。会话工厂是一个昂贵的东西，应该在应用程序启动时构建一次

经验法则是：会话生命周期需要足够长，以便在会话结束后不会有持久对象在作用域中挂起

会话结束后，您从该会话获得的对象的所有更改跟踪都将停止，因此除非您有意将该对象重新附加到新会话，否则这些更改不会保存。因此，只要从会话中获取的对象存在，会话就应该一直存在。在Web应用程序中，这通常意味着每个请求都有一个会话；在WinForms中，每个窗体的会话

在您的情况下，使用一个服务（我假设它运行<强> < /强> Windows服务）执行NHiBiess工作，您可能希望考虑为消费桌面应用程序创建每个新请求的会话，并在请求已被服务时处理它。我不知道你的服务是如何运行的，也不知道桌面应用程序使用什么机制与之对话（远程处理？WCF？普通的旧SOAP？），我不能说得更具体了

（此一般规则有一些例外-假设您有一组表示其他代码将引用但不会更改的共享资源的持久化对象，那么您可以在应用程序启动时提前加载这些对象，并使其从应用程序启动时断开连接。）

---

如果您发现在这种策略下性能缓慢，可能是因为您与数据库的对话太多，并且您的对象图很复杂；看看这个例子。

“每次操作的会话”相当模糊。在我看来，您应该提到“每个请求的会话”，因为EF 1.0/3.5不支持基于代理的自动延迟加载，EF和NHibernate在这个问题上的差异太大，无法有效地共享建议。EF中的ObjectContext生存期更易于管理，因为EF的功能并不丰富。您可以说EF 1.0不支持这一点，但EF 2.0支持这一点。这篇文章似乎适用于两者。谢谢！关于我的服务，我正在使用WCF，目前soap作为一个控制台应用程序运行，但我认为这不会有任何区别，所以您已经足够具体了。每个请求有一个会话听起来很合理。目前我只使用一个正在运行事务的会话，并且似乎有一些引用数据没有在事务期间加载，因为会话已关闭而失败。在您的问题中，您要求我研究这个新问题，但我看到您已经收到了足够的覆盖率。我支持这里的一些观点，但请注意，在讨论中，会议和交易似乎是混杂在一起的，而这些是不同的事情。此外，会话池或超时触发的会话在性能方面可能是有益的，但在设置和获得正确的结果时很棘手。还要注意，在引擎盖下，使用了连接池