我是一名学生，目前正在涉足使用 Nhibernate+WCF+WPF 的 .Net n-tier 应用程序。
其中一件非常糟糕的事情是对象图序列化，事实上它根本没有完成，目前关联被忽略了，我们到处都在使用 DTO。
据我所知，一种方法是预定义应该加载和序列化哪些对象和集合以通过网络，从而能够向客户端呈现一些关联，但这似乎是有限的、不灵活的和不一致的（你能告诉我不喜欢这个主意）。
我想到的一个选择是简单地将客户端层上延迟加载收集的 NHProxies 替换为“disconnectedProxy”，该代理将通过网络检索相关联的内容。这意味着我们必须稍微扩展我们的 Web 服务签名并对我们生成的代理做一些黑客攻击，但这似乎是一个很好的 T4/其他代码生成实验。
据我所知，这似乎是一个常见的绊脚石，但经过大量阅读后，我无法找出任何好的/普遍接受的解决方案。我正在寻找与任何特定解决方案一样多的方向，但如果有一种简单的方法可以让客户“感觉”连接，请告诉我。
你问了一个非常好的问题，不幸的是没有一个非常干净的答案。即使您能够通过 WCF 进行延迟加载（我们能够做到），您仍然会在使用代理拦截器时遇到问题。相信我，您需要客户端层上的 POCO 对象！
您真正需要考虑的...从我所看到的研究中，被认为是解决此问题的行业标准方法称为持久性与使用或持久性无知。换句话说，您的对象模型和映射代表您的持久性域，但它与您理想的使用场景不匹配。您不想将整个数据库带到客户端只是为了显示几个属性，对吗？
这似乎是一个简单的问题，但解决方案要么非常简单，要么非常复杂。一方面，您可以围绕使用场景设计实体，但最终会导致对象域的扩散，从而使其难以维护。另一方面，您仍然需要丰富的对象模型关系来编写细粒度的业务逻辑。
为了简化这个问题，让我们检查一下我们需要填补的两个主要空白……数据库和数据库/服务层之间以及服务到客户端之间的空白。NHibernate 通过提供一个 ORM 来将数据加载到您的对象中，很好地填充了第一个。它做得不错，但为了获得出色的性能，需要使用自定义加载策略进行调整。我跑题了……</p>
服务器和客户端之间的第二个差距是事情变得危险的地方。为简化起见，想象一下，如果您没有通过网络向客户端发送任何映射实体？尝试创建一种机制，将业务实体交换为 DTO 对象，同样将 DTO 对象交换为业务实体。这样，您的客户只处理 DTO（当然是 POCO），您的业务逻辑可以保持其丰富的结构。这使您不仅可以利用 NHibernate 的延迟加载机制，还可以利用会话带来的其他好处，例如 L1 缓存。
出于简洁和知识产权的原因，我不会进入所述机制的设计，但希望这些信息足以为您指明正确的方向。如果您根本不关心性能或延迟……只需将延迟加载全部关闭并解决序列化问题。
对我来说已经有一段时间了，但注入/断开的代理可能没有听起来那么糟糕。由于您是学生，我假设您有一些时间并想闲逛一下。
如果你想注入你自己的自定义序列化/反序列化逻辑，你可以使用IDataContractSurrogate，它可以使用DataContractSerializerOperationBehavior应用。我只做了一些基本的事情，但它可能值得研究。通过在这一层添加一些有趣的逻辑（阅读：可能是骇人听闻的），您也许可以使其更加连接。
这是一篇关于某人的 MSDN 帖子，他也有同样的认识，NHibernate 使用的 DynamicProxy 使得无法直接序列化 NHibernate 对象进行延迟加载。
如果您真的决定通过网络传输对象图并保留延迟加载功能。看看我在这里生成的一些代码http://slagd.com/?page_id=6。基本上，它会在网络的另一端创建一个假会话，并允许休眠代理保留其功能。并不是说这是做事的正确方式，但它可能会给你一些想法。