[原创] WCF技术剖析之十六：数据契约的等效性和版本控制

于 2009-07-21 23:07:00 发布
阅读量117 收藏
点赞数
文章标签： WCF 数据结构 XML
本文探讨了WCF中数据契约版本控制的关键问题，包括数据成员的添加与删除对序列化及反序列化的影响，并介绍了如何利用回调方法处理必备成员缺失的情况。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

[爱心链接：拯救一个25岁身患急性白血病的女孩[内有苏州电视台经济频道《天天山海经》为此录制的节目视频（苏州话）]]数据契约是对用于交换的数据结构的描述，是数据序列化和反序列化的依据。在一个WCF应用中，客户端和服务端必须通过等效的数据契约方能进行有效的数据交换。随着时间的推移，不可避免地，我们会面临着数据契约版本的变化，比如数据成员的添加和删除、成员名称或者命名空间的修正等，如何避免数据契约这种版本的变化对客户端现有程序造成影响，就是本节着重要讨论的问题。

一、数据契约的等效性

数据契约就是采用一种厂商中立、平台无关的形式（XSD）定义了数据的结构，而WCF通过DataContractAttribute和DataMemberAttribute旨在给相应的类型加上一些元数据，帮助DataContractSerializer将相应类型的对象序列化成具有我们希望结构的XML。在客户端，WCF的服务调用并不完全依赖于某个具体的类型，客户端如果具有与服务端完全相同的数据契约类型定义，固然最好。如果客户端现有的数据契约类型与发布出来数据契约具有一些差异，我们仍然可以通过DataContractAttribute和DataMemberAttribute这两个特性使该数据契约与之等效。

简言之，如果承载相同数据的两个不同数据契约类型对象最终能够序列化出相同的XML，那么这两个数据契约就可以看成是等效的数据契约。等效的数据契约具有相同的契约名称、命名空间和数据成员，同时要求数据成员出现的先后次序一致。比如，下面两种形式的数据契约定义，虽然它们的类型和成员命名不一样，甚至对应成员在各自类型中定义的次序都不一样，但是由于合理使用了DataContractAttribute和DataMemberAttribute这两个特性，确保了它们的对象最终序列化后具有相同的XML结构，所以它们是两个等效的数据契约。

   1: [DataContract(Namespace = "http://www.artech.com/")]
<!--CRLF--> 
   2: public class Customer
<!--CRLF--> 
   3: {
<!--CRLF--> 
   4:     [DataMember(Order=1)]
<!--CRLF--> 
   5:     public string FirstName
<!--CRLF--> 
   6:     {get;set;}
<!--CRLF--> 
   7:
<!--CRLF--> 
   8:     [DataMember(Order = 2)]
<!--CRLF--> 
   9:     public string LastName
<!--CRLF--> 
  10:     { get; set; }
<!--CRLF--> 
  11:
<!--CRLF--> 
  12:     [DataMember(Order = 3)]
<!--CRLF--> 
  13:     public string Gender
<!--CRLF--> 
  14:     { get; set; }
<!--CRLF--> 
  15: }
<!--CRLF--> 
   1: [DataContract(Name = "Customer", Namespace = "http://www.artech.com/")]
<!--CRLF--> 
   2: public class Contact
<!--CRLF--> 
   3: {
<!--CRLF--> 
   4:     [DataMember(Name = "LastName", Order = 2)]
<!--CRLF--> 
   5:     public string Surname
<!--CRLF--> 
   6:     { get; set; }
<!--CRLF--> 
   7:
<!--CRLF--> 
   8:     [DataMember(Name = "FirstName", Order = 1)]
<!--CRLF--> 
   9:     public string Name
<!--CRLF--> 
  10:     { get; set; }
<!--CRLF--> 
  11:
<!--CRLF--> 
  12:     [DataMember(Name = "Gender", Order = 3)]
<!--CRLF--> 
  13:     public string Sex
<!--CRLF--> 
  14:     { get; set; }
<!--CRLF--> 
  15: }
<!--CRLF-->

数据契约版本的差异最主要的表现形式是数据成员的添加和删除。如何保证在数据契约中添加一个新的数据成员，或者是从数据契约中删除一个现有的数据成员的情况下，还能保证现有客户端的正常服务调用（对于服务提供者），或者对现有服务的正常调用（针对服务消费者），这是数据契约版本控制需要解决的问题。

二、数据成员的添加

先来谈谈添加数据成员的问题，如下面的代码所示，在现有数据契约（CustomerV1）基础上，在服务端添加了一个新的数据成员: Address。但是客户端依然通过数据契约CustomerV1进行服务调用。那么，客户端按照CustomerV1的定义对于Customer对象进行序列化，服务端则按照CustomerV2的定义对接收的XML进行反序列化，会发现缺少Address成员。那么在这种数据成员缺失的情况下，DataContractSerializer又会表现出怎样的序列化与反序列化行为呢？

   1: [DataContract(Name = "Customer", Namespace = "http://www.artech.com")]
<!--CRLF--> 
   2: public class CustomerV1
<!--CRLF--> 
   3: {
<!--CRLF--> 
   4:     [DataMember]
<!--CRLF--> 
   5:     public string Name
<!--CRLF--> 
   6:     { get; set; }
<!--CRLF--> 
   7:
<!--CRLF--> 
   8:     [DataMember]
<!--CRLF--> 
   9:     public string PhoneNo
<!--CRLF--> 
  10:     { get; set; }
<!--CRLF--> 
  11: }
<!--CRLF--> 
   1: [DataContract(Name = "Customer", Namespace = "http://www.artech.com")]
<!--CRLF--> 
   2: public class CustomerV2
<!--CRLF--> 
   3: {
<!--CRLF--> 
   4:     [DataMember]
<!--CRLF--> 
   5:     public string Name
<!--CRLF--> 
   6:     { get; set; }
<!--CRLF--> 
   7:
<!--CRLF--> 
   8:     [DataMember]
<!--CRLF--> 
   9:     public string PhoneNo
<!--CRLF--> 
  10:     { get; set; }
<!--CRLF--> 
  11:
<!--CRLF--> 
  12:     [DataMember]
<!--CRLF--> 
  13:     public string Address
<!--CRLF--> 
  14:     { get; set; }
<!--CRLF--> 
  15: }
<!--CRLF-->

为了探求DataContractSerializer在数据成员缺失的情况下如何进行序列化与反序列化，我写了下面一个辅助方法Deserialize<T>用于反序列化工作。

   1: public static T Deserialize<T>(string fileName)
<!--CRLF--> 
   2: {
<!--CRLF--> 
   3:     DataContractSerializer serializer = new DataContractSerializer(typeof(T));
<!--CRLF--> 
   4:     using (XmlReader reader = new XmlTextReader(fileName))
<!--CRLF--> 
   5:     {
<!--CRLF--> 
   6:                 return (T)serializer.ReadObject(reader);
<!--CRLF--> 
   7:     }
<!--CRLF--> 
   8: }
<!--CRLF-->

通过下面的代码来模拟DataContractSerializer在XML缺少了数据成员Address时能否正常的反序列化：先将创建的CustomerV1对象序列化到一个XML文件中，然后读取该文件，按照CustomerV2的定义进行反序列化。从运行的结果可以得知，在数据成员缺失的情况下，反序列化依然可以顺利进行，只是会保留Address属性的默认值。

   1: string fileName = @"e:\customer.xml";
<!--CRLF--> 
   2: CustomerV1 customerV1 = new CustomerV1
<!--CRLF--> 
   3: {
<!--CRLF--> 
   4:     Name     = "Foo",
<!--CRLF--> 
   5:     PhoneNo     = "9999-99999999"
<!--CRLF--> 
   6: };
<!--CRLF--> 
   7: Serialize<CustomerV1>(customerV1, fileName);
<!--CRLF--> 
   8:
<!--CRLF--> 
   9: CustomerV2 customerV2 = Deserialize<CustomerV2>(fileName);
<!--CRLF--> 
  10: Console.WriteLine("customerV2.Name: {0}\ncustomerV2.PhoneNo: {1}\ncustomerV2.Address: {2}",
<!--CRLF--> 
  11: customerV2.Name ?? "Empty", customerV2.PhoneNo ?? "Empty", customerV2.Address ?? "Empty");
<!--CRLF-->

输出结果：

   1: customerV2.Name：Foo
<!--CRLF--> 
   2: customerV2.Phone：9999-99999999
<!--CRLF--> 
   3: customerV2.Address: Empty
<!--CRLF-->

如果我们从数据契约的另外一种表现形式（XSD）来理解这种序列化和反序列化行为，就会更加容易理解。下面是数据契约CustomerV2通过XSD的表示，从中可以看出对于表示数据成员的每一个XML元素，其minOccurs属性为“0”，就意味着所有的成员都是可以缺省的。由于基于CustomerV1对象序列化后的XML依然符合基于CustomerV2的XSD，所以能够确保反序列化的正常进行。

   1: <?xml version="1.0" encoding="utf-8"?>
<!--CRLF--> 
   2: <xs:schema elementFormDefault="qualified" targetNamespace="http://www.artech.com" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://www.artech.com">
<!--CRLF--> 
   3:     <xs:complexType name="Customer">
<!--CRLF--> 
   4:         <xs:sequence>
<!--CRLF--> 
   5:             <xs:element minOccurs="0" name="Address" nillable="true" type="xs:string"/>
<!--CRLF--> 
   6:             <xs:element minOccurs="0" name="Name" nillable="true" type="xs:string"/>
<!--CRLF--> 
   7:             <xs:element minOccurs="0" name="PhoneNo" nillable="true" type="xs:string"/>
<!--CRLF--> 
   8:         </xs:sequence>
<!--CRLF--> 
   9:     </xs:complexType>
<!--CRLF--> 
  10:     <xs:element name="Customer" nillable="true" type="tns:Customer"/>
<!--CRLF--> 
  11: </xs:schema>
<!--CRLF-->

在很多情况下，要对这些缺失的成员设置一些默认值。我们可以通过注册序列化回调方法的方式来初始化这些值。WCF允许我们通过自定义特性的方式注册序列化的回调方法，这些DataContractSerializer在进行序列化或者反序列化过程中，会回调你注册的回调方法。WCF中定义了4个这样的特性：OnSerializingAttribute，OnSeriallizedAttribute、OnDeserializingAttribute和OnDeserializedAttribute，相应的回调方法分别会在序列化之前、之后，以及反序列化之前、之后调用。

注： 上面4个特性只能用于方法上面，而且方法必须具有这样的签名：void Dosomething（StreamingContext context），即返回类型为void，具有唯一个StreamingContext类型参数。

比如在下面的代码中，通过一个应用了OnDeserializingAttribute特性的方法，为缺失成员Address指定了一个默认值。

   1: [DataContract(Name = "Customer", Namespace = "http://www.artech.com")]
<!--CRLF--> 
   2: public class CustomerV2
<!--CRLF--> 
   3: {
<!--CRLF--> 
   4:     //其他成员
<!--CRLF--> 
   5:     [OnDeserializing]
<!--CRLF--> 
   6:     void OnDeserializing(StreamingContext context)
<!--CRLF--> 
   7:     {
<!--CRLF--> 
   8:         this.Address = "Temp Address...";
<!--CRLF--> 
   9:     }
<!--CRLF--> 
  10: }
<!--CRLF-->

但是对于那些必备数据成员（DataMemberAttribute特性的IsRequired属性为true）缺失的情况，还能够保证正常的序列化与反序列化吗？

   1: [DataContract(Name = "Customer", Namespace = "http://www.artech.com")]
<!--CRLF--> 
   2: public class CustomerV2
<!--CRLF--> 
   3: {
<!--CRLF--> 
   4:     //其他成员
<!--CRLF--> 
   5:     [DataMember(IsRequired =true)]
<!--CRLF--> 
   6:     public string Address
<!--CRLF--> 
   7:     { get; set; }
<!--CRLF--> 
   8: }
<!--CRLF-->

在上面的代码中，我通过DataMemberAttribute的IsRequired属性将Address定义成数据契约的必备数据成员。如果我们运行上面的程序，将会抛出如图1所示SerializationException异常，提示找不到Address元素。

clip_image002

图1 缺少必须数据成员导致反序列化异常

对于上面的异常，仍然可以从XSD找原因。下面是包含必备成员Address的数据契约在XSD中的表示。我们可以清楚地看到Address元素的minOccurs="0"没有了，表明该元素是不能缺失的。由于XML不再符合XSD的定义，反序列化不能成功进行。

   1: <?xml version="1.0" encoding="utf-8"?>
<!--CRLF--> 
   2: <xs:schema elementFormDefault="qualified" targetNamespace="http://www.artech.com" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://www.artech.com">
<!--CRLF--> 
   3:     <xs:complexType name="Customer">
<!--CRLF--> 
   4:         <xs:sequence>
<!--CRLF--> 
   5:             <xs:element name="Address" nillable="true" type="xs:string"/>
<!--CRLF--> 
   6:             <xs:element minOccurs="0" name="Name" nillable="true" type="xs:string"/>
<!--CRLF--> 
   7:             <xs:element minOccurs="0" name="PhoneNo" nillable="true" type="xs:string"/>
<!--CRLF--> 
   8:         </xs:sequence>
<!--CRLF--> 
   9:     </xs:complexType>
<!--CRLF--> 
  10:     <xs:element name="Customer" nillable="true" type="tns:Customer"/>
<!--CRLF--> 
  11: </xs:schema>
<!--CRLF-->

三、数据成员的删除

讨论了数据成员添加的情况，接着讨论数据成员删除的情况。依然沿用Customer数据契约的例子，在这里，两个版本需要做一下转变：CustomerV1中定义了3个数据成员，在CustomerV2 中数据成员Address从成员列表中移除。如果DataContractSerializer按照CustomerV2的定义对CustomerV1的对象进行序列化，那么XML中将不会包含Address成员；同理，如果DataContractSerializer按照CustomerV2的定义反序列化基于CustomerV1的XML，仍然能够正常创建CustomerV2对象，因为CustomerV2的所有成员都存在于XML中。

   1: [DataContract(Name = "Customer", Namespace = "http://www.artech.com")]
<!--CRLF--> 
   2: public class CustomerV1
<!--CRLF-->
iteye_11848
关注
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值