WCF - 领域对象和IExtensibleDataObject

Question

典型情况下，我们在服务器群和多个分布式和本地客户端之间进行通信时，使用老式的XML Web Services。没有第三方涉及，只有我们和我们的客户使用的应用程序。

我们目前正在考虑从XML WS迁移到基于对象的WCF模型，并一直在尝试各种方法。其中一种方法涉及直接在线路上传输域对象/聚合，可能会在其上调用DataContract属性。

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

我经常听到我们应该在线路上使用专用的、仅用于传输的数据传输对象(DTOs)。

为什么？现在还需要这样做吗？当然，我们在服务器端和客户端使用相同的领域模型，在必要的时候预先填充集合等等。集合属性利用服务定位器原则和IoC来调用NHibernate-based“service”直接获取数据（在服务器端），并且客户端上的WCF“service”客户端用于与WCF服务器群交互。

所以-为什么我们需要使用DTO？

- HenningK

Answer 1

我曾经使用过共享领域对象和DTO的两种方法，但我认为，共享领域对象的最大问题在于当您无法控制所有客户端时，但根据我的过去经验，除非开发速度至关重要，否则通常会使用DTOs。

如果您无法始终控制客户端应用程序，则一定建议使用DTOs，因为一旦与其他人的客户端应用程序共享领域对象，就开始将内部绑定到其他人的开发周期。

当我们在版本化服务环境中工作时，我还发现DTOs很有用，这允许我们彻底更改我们应用程序的内部，但仍然接受旧版本服务接口的调用。

最后，如果您有许多客户端应用程序，则使用DTOs也可能是有益的，因为这样可以保护您具有易于版本化的服务。

- Ubiguchi

---

你是对的。在某个阶段，我们当然会涉及到第三方。但我想更多地考虑将所需功能作为“超级层”暴露给他们，放在这些WCF服务之上，并且只有在那时使用自定义DTOs。如果您愿意，可以为我们的WCF服务层创建一个适配器。 - HenningK

Answer 2

在我的经验中，DTO对于以下方面非常有用：

1. 严格定义将要通过网络发送的内容，并且拥有一个专用于该定义的类型。
2. 隔离应用程序、客户端和服务器免受未来更改的影响。
3. 与非.Net系统互操作。 DTO并不是必需的，但它们使得设计“安全”类型更加容易。

在你的情况中，这些设计特性可能并不那么重要。我使用过带有严格DTO和共享域对象的WCF，在这两种情况下都能正常工作。唯一需要注意的是，当我传送域对象时，我倾向于发送比实际需要更多的数据（以及以意外的方式）。这可能更多是由于我对WCF缺乏经验，而不是其他原因；但如果你选择这条路，这绝对是你需要小心的事情。

- akmad

---

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