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

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

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

我不断听到我们应该在网络上使用专用的，仅传输的数据传输对象(DTO)。

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

那么为什么我们需要使用DTO呢？

解决方案

回答

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

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

在方案中，这些设计功能可能没什么大不了的。我已经将WCF与严格的DTO和共享的域对象一起使用，并且在两种情况下都非常有效。通过电线发送域对象时，我唯一注意到的是，我倾向于发送比我需要的更多的数据(并且以意外的方式)。这很可能是由于我缺乏WCF的经验所致。但这绝对是我们应该警惕的事情，如果我们选择走那条路。

回答

在使用两种方法(共享域对象和DTO)一起工作时，我会说共享域对象的最大问题是当我们无法控制所有客户端时，但是根据我过去的经验，除非开发速度达到预期水平，否则我通常会使用DTO。精华。

如果我们有可能永远无法控制客户端，那么我绝对会推荐DTO，因为一旦我们与其他人的客户端应用程序共享域对象，我们便开始将内部结构与其他人的开发周期联系在一起。

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

最后，如果我们有很多客户端应用程序，则使用DTO可能也会有所帮助，因为这样便可以通过易于版本控制的服务对其进行保护。