WCF - 域对象和 IExtensibleDataObject答案

【问题标题】：WCF - Domain Objects and IExtensibleDataObjectWCF - 域对象和 IExtensibleDataObject
【发布时间】：2010-09-06 17:19:15
【问题描述】：

典型场景。我们使用老式 XML Web 服务 internally 在服务器群和多个分布式和本地客户端之间进行通信。不涉及第三方，只涉及我们自己和客户使用的应用程序。

我们目前正在考虑从 XML WS 转移到 WCF/object-based 模型，并且一直在尝试各种方法。其中之一涉及直接通过网络传输域对象/聚合，可能会在它们上调用 DataContract 属性。

通过使用IExtensibleDataObject 和使用DataMembers 上的Order 属性的DataContract，我们应该能够处理简单的属性版本控制问题（请记住，我们控制所有客户端并且可以轻松地强制更新它们）。

我一直听说我们应该通过网络使用专用的、仅传输的数据传输对象 (DTOs)。

为什么？还有理由这样做吗？我们在服务器端和客户端使用相同的域模型，当然，只有在认为正确和“必要”时才预填充集合等。集合属性利用服务定位器原理和 IoC 调用NHibernate-based“服务”直接获取数据（在服务器端），并在客户端调用WCF“服务”客户端与WCF 对话服务器场。

那么 - 为什么我们需要使用DTOs？

【问题讨论】：

标签： wcf serialization soap domain-driven-design soa

【解决方案1】：

在使用过这两种方法（共享域对象和 DTO）后，我想说共享域对象的最大问题是您无法控制所有客户端，但根据我过去的经验，我通常会使用 DTO，除非它进行开发速度至关重要。

如果您有可能无法始终控制客户端，那么我肯定会推荐 DTO，因为一旦您与其他人的客户端应用程序共享您的域对象，您就会开始将您的内部与其他人的开发人员联系起来循环。

我还发现 DTO 在版本化服务环境中工作时很有用，它允许我们从根本上改变应用程序的内部结构，但仍然接受对旧版本服务接口的调用。

最后，如果您有很多客户端应用程序，那么使用 DTO 也可能是有益的，因为您会受到易于版本控制的服务的保护。

【讨论】：

你是对的，当然。在某个阶段，我们将涉及第三方。但是我更多地考虑将所需的功能作为这些 WCF 服务之上的“超级层”向它们公开，然后才使用自定义 DTO。我们的 WCF 服务层的适配器，如果你愿意的话。

【解决方案2】：

根据我的经验，DTO 最有用的是：

严格定义将通过网络发送的内容并具有专门用于该定义的类型。
将应用程序、客户端和服务器的其余部分与未来的更改隔离开来。
与非 .Net 系统的互操作性。 DTO 当然不是必需的，但它们使设计“安全”类型变得更加容易。

在您的场景中，这些设计功能可能并不重要。我已经将 WCF 与严格的 DTO 和共享域对象一起使用，并且在这两种情况下它都工作得很好。当通过网络发送域对象时，我注意到的唯一一件事是我倾向于发送更多数据（并且以意想不到的方式），然后我需要。这可能更多是因为我缺乏 WCF 经验。但是，如果您选择走那条路，那么您绝对应该警惕这一点。

【讨论】：

是的，akmad，这些正是我一直有的想法。我们可能会采用一种混合这种方式的方法，在适当的情况下传输纯“实体”，但为更纯的业务流程类型调用采用更基于命令的“消息”格式。