10

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

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

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

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

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

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

4

2 回答 2

7

在使用过这两种方法（共享域对象和 DTO）后，我想说共享域对象的最大问题是当你不能控制所有客户端时，但根据我过去的经验，我通常会使用 DTO，除非它的开发速度是精华。

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

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

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

于 2008-09-01T22:44:24.800 回答
6

根据我的经验，DTO 最适用于：

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

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

于 2008-08-26T17:48:12.530 回答