数据契约

本书的第3章主要讲解了有关数据契约的知识。“从抽象层面看，WCF能够托管CLR类型（接口和类） 并将它们公开为服务，也能够以本地CLR接口和类的方式使用服务。WCF服务的操作接收和返回诸如int和string的CLR类型，WCF客户端则传递 和处理返回的CLR类型。然而，CLR类型却属于.NET的特定技术。由于面向服务的一个核心原则就是在跨越服务边界时，服务不能够暴露它们的实现技术。 因此，不管客户端采用了何种技术，它都能够与服务交互。显然，这就意味着WCF不允许在跨越服务边界时公开CLR数据类型。我们需要找到一种办法，实现 CLR数据类型与标准的与平台无关的表示形式之间的转换。这样的表示形式就是基于XML的样式或信息集（Infoset）。此外，服务需要一种正式的方法 声明两者之间的转换。这个方法就是本章所要介绍的主题——数据契约。本章的第一部分介绍了数据契约启用类型封送（Type Marshaling）与转换的方法，以及如何通过基础架构处理类的层级与数据契约的版本控制。第二部分则介绍了如何将不同的.NET类型，例如枚举、委 托、数据表以及集合，作为数据契约使用。”

数据契约是服务之间传递的数据。由于必须支持跨进程，乃至于跨机器的传递，WCF必须对数据进行特殊的处理，否则无法实现数据的传递。在.NET Remoting与Web Service中，对数据的处理方式通常是利用序列化的方法，WCF同样沿袭了这一做法，但为了更好的体现面向服务的特质，又特别引入了数据契约 （DataContract）。此外，WCF还引入了消息契约（MessageContract），但本书没有介绍。

WCF的序列化使用了.NET平台自身支持的序列化机制，因此这里不再重复。

.NET提供的序列化机制虽然足以应付SOA的要求，但仍然存在许多不足之处。本书总结了Serializable的缺陷：
“Serializable 所指代的涵义是类型的所有成员都是可序列化的，这些成员是组成类型数据样式的一部分。然而，更好的方式是能够提供一种明确参与（Opt-In）途径，只有 那些契约的开发者明确包含的成员才应该放到数据契约中。Serializable特性强制要求数据类型是可序列化的，从而使得类型可以被用作契约操作的参 数，但它却无法实现类型的服务特性（具有成为WCF操作参数的能力）与序列化能力之间的职责分离。Serializalbe特性不支持类型名和成员名的别 名，也无法将一个新类型映射为预定义的数据契约。由于Serializable特性可以直接操作成员字段，使得封装了字段访问的属性形同虚设。访问字段的 最好办法是通过属性添加它们的值，而Serializable却破坏了属性的封装性。最后，Serializable特性并没有直接支持版本控制 （Versioning），而版本控制的信息却是格式器期望获取的。无疑，它导致了版本控制的处理变得举步维艰。”

WCF提供的数据契约DataContract基本上解决了以上的问题。通常，DataContract必须与DataMember结合使用。只有 应用了DataMember特性的属性才被公开到元数据中。虽然DataMember特性也可以应用到对象的字段上，但WCF并不推荐这样做，原因与类的 设计原则相同。

数据契约与服务契约相似，数据成员或数据契约的访问限定与WCF之间并没有因果关系。数据契约完全可以包含私有数据成员等内部类型：

即使DataMember特性被直接应用到字段上，在导入的客户端定义仍然会以属性来表示。如下的数据契约定义：

导入的客户端定义为：

它会将字段名作为属性名，而导入的定义中，则在属性名后加上Field后缀作为字段名。但我们也可以手工修改客户端的定义。

如果数据契约的数据成员为私有的，导入的客户端定义会自动修改为公有的。“当DataMember特性应用到属性上时（不管是服务还是客户端），该 属性必须具有get和set访问器。如果没有，在调用时就会抛出InvalidDataContractException异常。因为当属性自身就是数据 成员时，WCF会在序列化和反序列化时使用该属性，使开发者能够将定制逻辑应用到属性中。”

“不要将DataMember特性既应用到属性上，又应用到相对应的字段上，这会导致导入的成员定义重复。”

如果服务端的数据被标记为Serializable特性，在导入这样的定义时，会使用DataContract。而且“对于每一个可序列化的成员，不管是公有的还是私有的，都是数据成员。” 

传统的格式器不能序列化只标记了DataContract特性的类型。要序列化这样的类型，必须同时应用DataContract特性和 Serializable特性。对于如此类型生成的传输型表示形式（Wire Representation），就好似仅仅应用了DataContract特性一般，同时，我们仍然需要为成员添加DataMember特性。

在WCF的数据契约中，很明显地体现出WCF还不能够完全支持面向对象的设计思想。在第2章对服务契约的描述中，对契约的继承层级的处理方式来看，已经体现了这一缺陷的端倪。而对于数据契约而言，更是进一步暴露了这样的缺陷。

首先WCF并不支持Liskov替换原则（LSP），“默认情况下，我们不能用数据契约的子类去替换基类。” 考虑如下的服务契约：

假定客户端同时定义了一个Customer类：

以下代码能够成功通过编译，但在运行时却会失败：

因为在这个例子中，我们传递了一个Customer对象，而不是Contact对象。由于服务无法识别Customer对象，也就无法反序列化它所接收到的Contact对象。

虽然WCF引入了Known Types（已知类型）来解决这一问题，然而对于理解面向对象思想的设计者而言，这样的设计无疑会引入父类与子类之间的耦合度。因为在我们设计父类的时候，就必须事先知道子类的定义。当我们需要扩展子类时，还需要修改父类的定义。

WCF引入的服务已知类型，比较已知类型而言，有一定程度的改善。因为它可以将父类与子类在层级上的耦合度缩小到方法级上。但这样的耦合，依然是不可接受的。例如：

当然，服务已知类型也可以应用到契约接口上，此时，该契约以及实现该契约的所有服务包含的所有操作都能够接收已知的子类。

为了解决这一问题，WCF提供了配置已知类型的方法。例如：

注意上述的配置文件中，我们配置的已知类型必须是类型的fullname。包括命名空间、版本号、Culture等。虽然这种方式可以避免在增加子类的情况下，修改代码、重新编译和重新部署，但无疑加重了开发者的负担，尤其是对配置文件的管理以及后期的维护。

不过，“如果已知类型对于另一个程序集而言是内部（internal）类型，要添加一个已知类型，只有使用配置文件声明它。”

总之，在WCF中要实现面向对象的多态，还未能做到最佳。如果能够将KnownType特性应用到子类上，为子类指名它所继承的父类，无疑更加利于类的扩展。遗憾的是WCF未能做到这一点。

如果数据契约本身实现了一个接口，情况就变得有趣了。从服务端的定义来看，这样的数据契约仍然可以通过服务已知类型在服务契约上指定实现了数据契约接口的子数据契约类型。例如，数据契约Contact类实现了接口IContact：

那么在处理数据契约Contact的服务契约中，如果契约的操作需要以抽象方式，定义IContact类型的参数，就必须使用ServiceKnownType特性指名其实现类Contact，如下所示：

注意，此时不能利用KnownType特性，将其直接应用到IContact接口上，因为导出的元数据无法包含接口本身。

服务端的定义无疑符合面向接口编程思想，除了增加了ServiceKnownType之外，整个设计还算优雅。然而根据这样的定义所导出的服务契约，却未免显得差强人意，如下所示：

导出定义中，将应用到契约的ServiceKnownType特性应用到了每个操作上，并且为每个操作都指定了具体的数据契约子类以及一个 object[]类型。特别要注意，在操作的返回值与参数中，原来的IContact类型全部被转换为了object类型。原因在于，客户端并没有 IContact接口的定义。基于object的契约定义无疑不具备类型安全性。

解决办法自然是在客户端中增加IContact接口的定义。如此，客户端定义就可以修改为：

但是，我们不能以具体的数据契约类型Contact，来替换原来的object类型。因为替换为具体的数据契约类型，则客户端的服务契约就与服务端的服务契约不兼容了。所以，下面的定义是错误的：