NHibernate 会话的生命周期应该是多长？

我是 NHibernate 的新手，在过早关闭会话时遇到了一些问题。我通过重用会话而不是为每个事务打开一个会话来暂时解决了这个问题。然而，我的印象是，每次需要时打开会话是会话生命周期管理的推荐方法。不？

所以;处理会话的推荐方法是什么？他们的一生应该是怎样的？一次交易？一个单例会话可以处理所有事情？或者是什么？

Edit:

请注意，我的应用程序架构是一个与服务器端服务通信的桌面应用程序，这是使用 NHibernate + Fluent 进行所有数据库处理的内容。 （如果这有什么区别的话......）

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

创建会话是一个成本低廉的过程，并且需要很少的前期 RAM 或 CPU，因此您不必担心保存或重复使用会话（事实上，重复使用它们可能会导致一些令人讨厌的和不可预见的副作用）。会话工厂是昂贵的东西，应该在应用程序启动时构建一次且仅一次。

经验法则是：会话生存期需要足够长，以便在会话结束后不会有持久对象在范围内徘徊。

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

在你的情况下，使用服务（我假设它正在运行as一个 Windows 服务）执行 NHibernate 工作，您可能希望考虑为来自消费桌面应用程序的每个新请求创建一个会话，并在该请求得到服务后将其释放。不确切地知道您的服务如何运行以及桌面应用程序使用什么机制与之通信（远程处理？WCF？普通的旧式 SOAP？）我真的无法更具体。

（这个一般规则有一些例外 - 假设您有一组持久对象，它们代表其他代码将引用但不会更改的共享资源，您可以在应用程序启动时预先加载这些对象，然后让它们断开连接在。）

如果您发现在这种策略下性能缓慢，可能是因为您与数据库的对话过多并且您的对象图很复杂；看着二级缓存 https://www.hibernate.org/hib_docs/nhibernate/html/caches.html在这种情况下。