数据契约是服务之间传递的数据。由于必须支持跨进程，乃至于跨机器的传递，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特性被直接应用到字段上，在导入的客户端定义仍然会以属性来表示。如下的数据契约定义：[DataContract] struct Contact { [DataMember] string m_FirstName; [DataMember] string m_LastName; }
[DataContract] struct Contact { [DataMember] public string FirstName; [DataMember] public string LastName; }
导入的客户端定义为：
它会将字段名作为属性名，而导入的定义中，则在属性名后加上Field后缀作为字段名。但我们也可以手工修改客户端的定义。[DataContract] public partial struct Contact { string FirstNameField; string LastNameField; [DataMember] public string FirstName { get { return FirstNameField; } set { FirstNameField = value; } } [DataMember] public string LastName { get { return LastNameField; } set { LastNameField = value; } } }
如果数据契约的数据成员为私有的，导入的客户端定义会自动修改为公有的。“当DataMember特性应用到属性上时（不管是服务还是客户端），该属性必须具有get和set访问器。如果没有，在调用时就会抛出InvalidDataContractException异常。因为当属性自身就是数据成员时，WCF会在序列化和反序列化时使用该属性，使开发者能够将定制逻辑应用到属性中。”
“不要将DataMember特性既应用到属性上，又应用到相对应的字段上，这会导致导入的成员定义重复。”
如果服务端的数据被标记为Serializable特性，在导入这样的定义时，会使用DataContract。而且“对于每一个可序列化的成员，不管是公有的还是私有的，都是数据成员。”
传统的格式器不能序列化只标记了DataContract特性的类型。要序列化这样的类型，必须同时应用DataContract特性和Serializable特性。对于如此类型生成的传输型表示形式（Wire Representation），就好似仅仅应用了DataContract特性一般，同时，我们仍然需要为成员添加DataMember特性。 在WCF的数据契约中，很明显地体现出WCF还不能够完全支持面向对象的设计思想。在第2章对服务契约的描述中，对契约的继承层级的处理方式来看，已经体现了这一缺陷的端倪。而对于数据契约而言，更是进一步暴露了这样的缺陷。
首先WCF并不支持Liskov替换原则（LSP），“默认情况下，我们不能用数据契约的子类去替换基类。” 考虑如下的服务契约：
假定客户端同时定义了一个Customer类：[ServiceContract] interface IContactManager { //Cannot accept Customer object here: [OperationContract] void AddContact(Contact contact); //Cannot return Customer objects here: [OperationContract] Contact[] GetContacts( ); }
以下代码能够成功通过编译，但在运行时却会失败：[DataContract] class Customer : Contact { [DataMember] public int OrderNumber; }
因为在这个例子中，我们传递了一个Customer对象，而不是Contact对象。由于服务无法识别Customer对象，也就无法反序列化它所接收到的Contact对象。Contact contact = new Customer( ); contact.FirstName = "Juval"; contact.LastName = "Lowy"; ContactManagerClient proxy = new ContactManagerClient( ); //Service call will fail: proxy.AddContact(contact); proxy.Close( );
虽然WCF引入了Known Types（已知类型）来解决这一问题，然而对于理解面向对象思想的设计者而言，这样的设计无疑会引入父类与子类之间的耦合度。因为在我们设计父类的时候，就必须事先知道子类的定义。当我们需要扩展子类时，还需要修改父类的定义。
WCF引入的服务已知类型，比较已知类型而言，有一定程度的改善。因为它可以将父类与子类在层级上的耦合度缩小到方法级上。但这样的耦合，依然是不可接受的。例如：
当然，服务已知类型也可以应用到契约接口上，此时，该契约以及实现该契约的所有服务包含的所有操作都能够接收已知的子类。[DataContract] class Contact {...} [DataContract] class Customer : Contact {...} [ServiceContract] interface IContactManager { [OperationContract] [ServiceKnownType(typeof(Customer))] void AddContact(Contact contact); [OperationContract] Contact[] GetContacts( ); }
为了解决这一问题，WCF提供了配置已知类型的方法。例如：
注意上述的配置文件中，我们配置的已知类型必须是类型的fullname。包括命名空间、版本号、Culture等。虽然这种方式可以避免在增加子类的情况下，修改代码、重新编译和重新部署，但无疑加重了开发者的负担，尤其是对配置文件的管理以及后期的维护。<system.runtime.serialization> <dataContractSerializer> <declaredTypes> <add type = "Contact,Host,Version=1.0.0.0,Culture=neutral, PublicKeyToken=null"> <knownType type = "Customer,MyClassLibrary,Version=1.0.0.0, Culture=neutral,PublicKeyToken=null"/> </add> </declaredTypes> </dataContractSerializer> </system.runtime.serialization>
不过，“如果已知类型对于另一个程序集而言是内部（internal）类型，要添加一个已知类型，只有使用配置文件声明它。”
总之，在WCF中要实现面向对象的多态，还未能做到非常好的。如果能够将KnownType特性应用到子类上，为子类指名它所继承的父类，无疑更加利于类的扩展。遗憾的是WCF未能做到这一点。
如果数据契约本身实现了一个接口，情况就变得有趣了。从服务端的定义来看，这样的数据契约仍然可以通过服务已知类型在服务契约上指定实现了数据契约接口的子数据契约类型。例如，数据契约Contact类实现了接口IContact：
那么在处理数据契约Contact的服务契约中，如果契约的操作需要以抽象方式，定义IContact类型的参数，就必须使用ServiceKnownType特性指名其实现类Contact，如下所示：interface IContact { string FirstName {get;set;} string LastName {get;set;} } [DataContract] class Contact : IContact {...}
注意，此时不能利用KnownType特性，将其直接应用到IContact接口上，因为导出的元数据无法包含接口本身。[ServiceContract] [ServiceKnownType(typeof(Contact))] interface IContactManager { [OperationContract] void AddContact(IContact contact); [OperationContract] IContact[] GetContacts( ); }
服务端的定义无疑符合面向接口编程思想，除了增加了ServiceKnownType之外，整个设计还算优雅。然而根据这样的定义所导出的服务契约，却未免显得差强人意，如下所示：
导出定义中，将应用到契约的ServiceKnownType特性应用到了每个操作上，并且为每个操作都指定了具体的数据契约子类以及一个object[]类型。特别要注意，在操作的返回值与参数中，原来的IContact类型全部被转换为了object类型。原因在于，客户端并没有IContact接口的定义。基于object的契约定义无疑不具备类型安全性。[ServiceContract] public interface IContactManager { [OperationContract] [ServiceKnownType(typeof(Contact))] [ServiceKnownType(typeof(object[]))] void AddContact(object contact); [OperationContract] [ServiceKnownType(typeof(Contact))] [ServiceKnownType(typeof(object[]))] object[] GetContacts( ); }
解决办法自然是在客户端中增加IContact接口的定义。如此，客户端定义就可以修改为：
但是，我们不能以具体的数据契约类型Contact，来替换原来的object类型。因为替换为具体的数据契约类型，则客户端的服务契约就与服务端的服务契约不兼容了。所以，下面的定义是错误的：[ServiceContract] public interface IContactManager { [OperationContract] [ServiceKnownType(typeof(Contact))] void AddContact(IContact contact); [OperationContract] [ServiceKnownType(typeof(Contact))] IContact[] GetContacts( ); }
[ServiceContract] public interface IContactManager { [OperationContract] void AddContact(Contact contact); [OperationContract] Contact[] GetContacts( ); }
