从 n 层客户端遍历对象图答案

【问题标题】：traversing object graph from n-tier client从 n 层客户端遍历对象图
【发布时间】：2008-12-19 01:46:30
【问题描述】：

我是一名学生，目前正在涉足使用 Nhibernate+WCF+WPF 的 .Net n-tier 应用程序。

其中一件非常糟糕的事情是对象图序列化，事实上它根本没有完成，目前关联被忽略了，我们到处都在使用 DTO。

据我所知，一种方法是预先定义哪些对象和集合应该被加载和序列化以通过网络，从而能够向客户端呈现一些关联，但这似乎是有限的、不灵活的和不一致的（你能说我不喜欢这个主意吗）。

我想到的一个选择是简单地将客户端层上的延迟加载收集的 NHProxies 替换为“disconnectedProxy”，该“disconnectedProxy”将通过网络检索相关联的内容。这意味着我们必须稍微扩展我们的 Web 服务签名并对我们生成的代理进行一些黑客攻击，但这似乎是一个很好的 T4/其他代码生成实验。

据我所知，这似乎是一个常见的绊脚石，但经过大量阅读后，我无法找出任何好的/普遍接受的解决方案。我正在寻找与任何特定解决方案一样多的方向，但如果有一种简单的方法可以让客户“感觉”连接，请告诉我。

【问题讨论】：

标签： wcf nhibernate serialization n-tier-architecture

【解决方案1】：

您提出了一个非常好的问题，但遗憾的是没有一个非常明确的答案。即使您能够通过 WCF 进行延迟加载（我们能够做到），您仍然会在使用代理拦截器时遇到问题。相信我，您需要客户端层上的 POCO 对象！

您真正需要考虑的...根据我所看到的研究，什么被认为是解决此问题的行业标准方法，称为持久性与使用或持久性无知。换句话说，您的对象模型和映射代表您的持久性域，但它与您理想的使用场景不匹配。您不想将整个数据库带到客户端只是为了显示几个属性，对吗？？

这似乎是一个简单的问题，但解决方案要么非常简单，要么非常复杂。一方面，您可以围绕使用场景设计实体，但最终会导致对象域的扩散，从而使其难以维护。另一方面，您仍然需要丰富的对象模型关系来编写细粒度的业务逻辑。

为了简化这个问题，让我们检查一下我们需要填补的两个主要差距……数据库和数据库/服务层之间以及服务到客户端的差距。 NHibernate 通过提供一个 ORM 来将数据加载到您的对象中，很好地填充了第一个。它做得不错，但为了获得出色的性能，需要使用自定义加载策略进行调整。我跑题了……

服务器和客户端之间的第二个差距是事情变得危险的地方。为简化起见，想象一下，如果您没有通过网络向客户端发送任何映射实体？尝试创建一种机制，将业务实体交换为 DTO 对象，同样将 DTO 对象交换为业务实体。这样，您的客户只处理 DTO（当然是 POCO），您的业务逻辑可以保持其丰富的结构。这使您不仅可以利用 NHibernate 的延迟加载机制，还可以利用会话的其他好处，例如 L1 缓存。

出于简洁和知识产权的原因，我不会详细介绍上述机制的设计，但希望这些信息足以为您指明正确的方向。如果您根本不关心性能或延迟……只需将延迟加载全部关闭并解决序列化问题。

【讨论】：

【解决方案2】：

对我来说已经有一段时间了，但注入/断开连接的代理可能没有听起来那么糟糕。由于您是一名学生，我假设您有一些时间并且想闲逛一下。

如果您想注入您自己的自定义序列化/反序列化逻辑，您可以使用IDataContractSurrogate，它可以使用DataContractSerializerOperationBehavior 应用。我只做了一些基本的事情，但它可能值得研究。通过在这一层添加一些有趣的逻辑（阅读：可能是骇人听闻的），您也许可以使其更加紧密。

Here 是一篇 MSDN 帖子，关于某人的相同认识，NHibernate 使用的 DynamicProxy 使得无法直接序列化执行延迟加载的 NHibernate 对象。

【讨论】：

【解决方案3】：

如果您真的决定通过网络传输对象图并保留延迟加载功能。看看我在这里生成的一些代码http://slagd.com/?page_id=6。基本上，它会在网络的另一端创建一个假会话，并允许休眠代理保留其功能。并不是说这是正确的做事方式，但它可能会给你一些想法。

【讨论】：