我是一名学生，目前正在涉足使用 Nhibernate+WCF+WPF 的 .Net n 层应用。
其中一件做得非常糟糕的事情是对象图序列化，事实上它根本没有完成，目前关联被忽略，我们到处都在使用 DTO。
据我所知，一种继续进行的方法是预定义哪些对象和集合应该被加载和序列化以通过网络，从而能够向客户端呈现一些关联，但这似乎是有限的、不灵活的和不一致的(你能看出我不喜欢这个想法吗)。
我想到的一个选择是简单地将客户端层上延迟加载集合的 NHProxies 替换为“disconnectedProxy”，它将通过网络检索相关内容。这意味着我们必须稍微扩展我们的 Web 服务签名并对我们生成的代理进行一些黑客攻击，但这似乎是一个很好的 T4/其他代码生成实验。
据我所知，这似乎是一个常见的绊脚石，但经过大量阅读后，我还没有找到任何好的/普遍接受的解决方案。我正在寻找与任何特定解决方案一样多的方向，但如果有一种简单的方法可以让客户“感觉”连接，请告诉我。
最佳答案
您提出了一个非常好的问题，不幸的是没有一个非常明确的答案。即使您能够通过 WCF 进行延迟加载(我们能够做到)，您仍然会在使用代理拦截器时遇到问题。相信我，您需要客户端层上的 POCO 对象!
您真正需要考虑的是……根据我所见的研究，被认为是解决此问题的行业标准方法称为持久性与使用或持久性无知。换句话说，你的对象模型和映射代表了你的持久域，但它不符合你理想的使用场景。你不想把整个数据库带到客户端只是为了显示几个属性吧？？
这似乎是一个如此简单的问题，但解决方案要么非常简单，要么非常复杂。一方面，您可以围绕您的使用场景设计您的实体，但您最终会导致对象域的激增，从而难以维护。另一方面，您仍然需要丰富的对象模型关系来编写细粒度的业务逻辑。
为了简化这个问题，让我们检查一下我们需要填补的两个主要差距……数据库和数据库/服务层之间以及对客户端的服务差距。 NHibernate 通过提供一个 ORM 来将数据加载到您的对象中，从而很好地填充了第一个。它做得不错，但为了获得出色的性能，需要使用自定义加载策略对其进行调整。我离题了……
服务器和客户端之间的第二个差距是事情变得危险的地方。为简化起见，假设您没有通过线路向客户端发送任何映射实体？尝试创建一种机制，将业务实体交换为 DTO 对象，同样将 DTO 对象交换为业务实体。这样你的客户只处理 DTO(当然是 POCO)，你的业务逻辑可以保持其丰富的结构。这使您不仅可以利用 NHibernate 的延迟加载机制，还可以利用 session 的其他好处，例如 L1 缓存。
出于简洁和知识产权的原因，我不会深入探讨上述机制的设计，但希望这些信息足以为您指明正确的方向。如果您根本不关心性能或延迟……只需将延迟加载全部关闭并解决序列化问题。
关于wcf - 从 n 层客户端遍历对象图，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/379897/