关于序列化：WCF-域对象和IExtensibleDataObject

WCF - Domain Objects and IExtensibleDataObject

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

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

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

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

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

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

曾经使用过两种方法(共享域对象和DTO)，我会说共享域对象的最大问题是当您不控制所有客户端时，但是根据我过去的经验，除非开发，我通常会使用DTO。速度至关重要。

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

我还发现DTO在版本化服务环境中工作时很有用，这使我们能够从根本上更改应用程序的内部结构，但仍可以接受对服务接口旧版本的调用。

最后，如果您有很多客户端应用程序，那么使用DTO可能也会有好处，因为这样可以通过易于版本控制的服务对其进行保护。

以我的经验，DTO对于以下方面最有用：

严格定义将通过网络发送的内容，并具有专门用于该定义的类型。

将其余的应用程序，客户端和服务器与将来的更改隔离开。

与非.Net系统的互操作性。 DTO当然不是必需的，但它们使设计"安全"类型更加容易。

在您的方案中，这些设计功能可能没有太大关系。我已经将WCF与严格的DTO和共享的域对象一起使用，并且在两种情况下都非常有效。通过有线发送域对象时，我唯一注意到的是，我倾向于发送比我需要的更多的数据(并且以意外的方式)。这可能更多是由于我对WCF缺乏经验，而不是其他任何原因。但这绝对是您应该警惕的选择。