我发现在桌面应用程序中管理会话要困难得多，因为我们无法利用HttpContext这样的明确绑定。
那么，如何管理会话生存期以利用延迟加载却又没有为整个应用程序打开一个会话的优势？

解决方案

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

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

另一方面，一旦用户选择了该记录进行查看/编辑，并且我们输入了对象的多页详细信息视图，那么我们便将延迟加载应用于特定对象。现在，根据仅按需查看的详细信息来延迟加载数据。这样，只要使用了Details视图，就可以持续打开我的会话以进行延迟加载。

如前所述，我们无法使用HttpRequest的边界，但是我们可以了解桌面应用程序中的" HttpRequest"。

让我解释。通常，HttpRequest将是操作的控制器，并且我们将会话限制为该特定操作。现在，在桌面应用程序中，"控制器"(事件)可以变小，但是正如@Jon所说，窗口可以轻松地代表边界：我们在此处处理事物，让它们进入会话。

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

无论如何，这与持久性无关，因为当我加载对象并且我(想要)仅处理普通实例时(我在这里特别指的是惰性加载)。

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

谢谢，
马切洛

Ayende最近在MSDN上写了一篇很棒的文章。