NHibernate在桌面应用程序中的会话管理策略是什么？

Question

我发现在桌面应用程序中管理会话要困难得多，因为你无法利用像HttpContext这样明确的键盘。 那么如何管理会话生命周期以利用延迟加载但没有为整个应用程序打开一个会话？

Answer 1

Ayende最近写了a great article on the subject in MSDN。

Answer 2

我认为归结为对象的设计。因为可以在每个对象级别强制执行延迟加载，所以在考虑会话管理时可以利用这一事实。

例如，我有一堆数据丰富且延迟加载的对象，我有一个网格/摘要视图，以及它们的详细信息视图。在网格摘要视图中，我不使用对象的延迟加载版本。我使用代理对象来呈现该数据，并且该代理对象不是延迟加载的。

另一方面，一旦用户选择该记录进行查看/编辑，并输入对象的多页面详细信息视图，那就是我们将延迟加载应用于特定对象的时间。数据现在是延迟加载的，具体取决于仅按需查看的详细信息。这样，只要正在使用详细信息视图，我的会话的延迟加载范围就会持续。

Answer 3

如前所述，您无法使用HttpRequest的边界，但您可以了解桌面应用程序中的“HttpRequest”。

让我解释一下。通常，您的HttpRequest将成为操作的控制器，您将会话限制为该特定操作。现在在你的桌面应用程序中，“控制器”（事件）可以更小，但正如@Jon所说，一个窗口很容易代表一个边界：你在那里工作，让他们在你的会话上。

Answer 4

也许我们可以想到一个Command模式设置。每个有意义的事件将提供并触发命令，然后执行它。基本的AbstractCommand.Execute（）实现负责初始化会话，包装事务，调用具体的SomeCommand._Execute（）实现并关闭所有东西。

无论如何，这远不是持久性不可知的，因为它应该是我加载了我的对象而我（想）只处理普通实例（我特别指的是这里的延迟加载）。

是否可以实现某种自动打开/自动关闭行为？这应该通过使持久层对更高层的查询需求敏感来实现，即使在诸如延迟加载触发器的隐式情况下也是如此。至于关闭连接，持久层可能会在DB不活动的给定超时（10秒？）后关闭。 我知道，这并不尖锐。但它确实会使更高层的持久性不可知。

谢谢， 马塞罗