WCF技术剖析之十四：泛型数据契约和集合数据契约（上篇）-白红宇

原文:

[爱心链接：]在.NET Framework 2.0中，泛型第一次被引入。我们可以定义泛型接口、泛型类型、泛型委托和泛型方法。序列化依赖于真实具体的类型，而泛型则刻意模糊了具体类型概念。而集合代表一组对象的组合，集合具有可迭代（Enumerable）的特性，可以通过某个迭代规则遍历集合中的每一个元素。由于范型类型和集合类型在序列化和反序列化上具有一些特殊的行为和规则，在这篇文章中，我将会对此进行详细介绍。上篇先来说所泛型数据契约。

一、泛型与数据契约

面向对象通过继承实现了代码的重用，而泛型则实现了“算法的重用”。我们定义一种算法，比如排序、搜索、交换、比较或者转换等等，为了实现尽可能的重用，我们并不限定该算法操作对象的具体类型，而通过一个泛型类型来表示。在真正创建范型对象或者调用该方法的时候，才指定其具体的类型。

就实现来说，泛型是CLR和编程语言（或者是基于编程语言的编译器）共同实现的一种特殊机制；就泛型的概念来说，这是面向对象的范畴。而我们现在介绍的数据契约，则属于面向服务的概念。两者具有一些冲突，比如面常服务没有继承、重载的概念一样，面向服务同样也无法理解泛型。

但是基于WCF的编程语言是C#、VB.NET这样的完全面向对象的编程语言，而WCF服务却是基于面向服务的。所以，从某种意义上讲，WCF的一个重大的作用就是弥合面向对象编程（OOP）和面向服务架构（SOA）之间的差异。我们现在就来看看WCF做了些什么使我们能够以泛型类型的形式来定义数据契约。

二、泛型数据契约的默认序列化规则

我们首先通过一个简单的例子看看DataContractSerializer是如何序列化一个范型对象的。为此我定义一个泛型类型Bill<BillHeader, BillDetail>，代表一个一般意义上的单据，BillHeader和BillDetail代表单据报头的明细的类型。两个属性Header和Details表示单据报头和明细列表。

namespace Artech.DataContractSerializerDemos
{
    [DataContract(Namespace="http://www.artech.com/")]
    public class Bill
    {
        [DataMember(Order = 1)]
        public BillHeader Header
        { get; set; }
 
        [DataMember(Order = 2)]
        public BillDetail[] Details
        { get; set; }
    }
}

然后我们定义用于描述订单单据的报头和明细的类型：OrderBillHeader和OrderBillDetail。OrderBillHeader描述定单的总体信息，OrderBillDetail实际上表示订单中每一个产品的ID、单价和数量。

namespace Artech.DataContractSerializerDemos
{
    [DataContract(Namespace="http://www.artech.com/")]
    public class OrderBillHeader
    {
        [DataMember]
        public Guid OrderID
        { get; set; }
 
        [DataMember]
        public DateTime Date
        { get; set; }
 
        [DataMember]
        public string Customer
        { get; set; }
    }
 
    [DataContract(Namespace="http://www.artech.com/")]
    public class OrderBillDetail
    {
        [DataMember]
        public Guid ProductID
        { get; set; }
 
        [DataMember]
        public int Quantity
        { get; set; }
 
        [DataMember]
        public double UnitPrice
        { get; set; }
    }
}

通过下面一个方法创建泛型类型Bill<BillHeader, BillDetail>对象，泛型类型指定为上面定义的OrderBillHeader和OrderBillDetail。

private static Bill
        CreateOrderBill()
{
    OrderBillHeader header = new OrderBillHeader
    {
        OrderID     = Guid.NewGuid(),
        Date         = DateTime.Today,
        Customer     = "Foo"
    };
 
    IList
        details = new List
        ();
    OrderBillDetail detail = new OrderBillDetail
    {
        ProductID     = Guid.NewGuid(),
        Quantity     = 20,
        UnitPrice     = 888
    };
    details.Add(detail);
    detail = new OrderBillDetail
    {
        ProductID     = Guid.NewGuid(),
        Quantity     = 10,
        UnitPrice     = 9999
    };
    details.Add(detail);
 
 
    Bill
        orderBill = new Bill
        ()
    {
        Header     = header,
        Details     = details.ToArray
       ()
    };
    return orderBill;
}

借助在《》定义的Serialize<T>辅助方法，我们对创建Bill<OrderBillHeader, OrderBillDetail>对象进行序列化。最终对象将被序列化成如下的XML。

1: Bill
        orderBill = CreateOrderBill();
2: Serialize
        >(orderBill, @"orderbill.xml");

1: 
2:     
3:         
       NCS
4:         
       2008-12-04T00:00:00+08:00
5:         
       15a62aae-c955-4bc0-acb6-e171fb9fe085
6:     
7:     
8:         
9:             
       f7679949-938a-40a0-a32a-5dde5c85e55f
10:             
       20
11:             
       888
12:         
13:         
14:             
       bbd750ff-8b0c-48f5-ab1f-5ad7e51bd420
15:             
       10
16:             
       9999
17:         
18:     
19: 

XML整体的结构正是我们希望的，关键是根节点名称，也就是数据契约的名称，“BillOfOrderBillHeaderOrderBillDetail6Of3LqKh”，会让有些人难以理解。我们仔细分析一下数据契约的名称，会发现它的组成结构是这样的：{类型名称（Bill）}+ Of + {第一个范型参数的类型（OrderBillHeader）} + {第二个范型参数的类型（OrderBillDetail）}+ {哈希值（6Of3LqKh）}。

这里说泛型参数的类型，实际上是不对的，应该说OrderBillHeader和OrderBillDetail的泛型类型对应的数据契约的名称。在下面的代码中。通过 DataContractAttribute特性修改了数据契约的名称（OrderHeader和OrderDetail），最终的数据契约的名称将会变成：BillOfOrderHeaderOrderDetail6Of3LqKh。可以看出描述泛型数据契约的部分内容相应地改变了。可能仔细的读者已经发现了，哈希值部分却没有发生变化，依然是“6Of3LqKh”，这是因为这是泛型类型（含命名空间）的哈希值，而不是数据契约名称的哈希值。所以我们可以将默认的基于泛型类型的命名规则表示成：[类型名称][范型数据契约名称1][ 范型数据契约名称2][…][含命名空间的范型类型哈希值]。

namespace Artech.DataContractSerializerDemos
{
    [DataContract(Name="OrderHeader")]
    public class OrderBillHeader
    {
        //省略成员
    }
 
    [DataContract(Name = "OrderDetail")]
    public class OrderBillDetail
    {
        //省略成员
    }
}

WCF之所以要采用这样的数据契约命名方式，是为了解决命名冲突，保证数据契约名称的唯一性。我们说了，面向服务下的数据契约完全没有泛型的概念，对它来说所有的类型都是“实实在在”的具体类型。对于泛型类型Bill<BillHeader，BillDetail>，不同的BillHeader和BillDetail组合代表不同的数据契约，所以最终的数据契约的名称需要由自身类型和泛型契约名称派生出来。由于在定义数据契约的时候，不同的CLR类型可以指定相同的数据契约名称，所以加上一个基于所有范型类型（含命名空间）的哈希值可以确保数据契约的唯一性。

WCF在进行元数据发布的时候，会自动按照这样的命名机制创建数据契约，并以XSD的形式发布出来。所以当客户端导入元数据生成客户端代码的时候，生成的等效数据契约的类型名称就是这个经过拼接的名称。下面是Bill<OrderBillHeader, OrderBillDetail>导入的形式。

public partial class BillOfOrderBillHeaderOrderBillDetail6Of3LqKh : object, System.Runtime.Serialization.IExtensibleDataObject, System.ComponentModel.INotifyPropertyChanged
{
    //省略成员
}

三、如何显式指定契约名称

如果你能够确保命名不会发生冲突，你可以通过DataContractAttribute特性的Name属性对数据契约的名称进行显式设置。比如在下面的代码中，将契约名称限定为“OrderBill”。不过这样设置就意味着你假定泛型类型只能表示基于订单的单据了，这相当于失去了泛型的意义。

namespace Artech.DataContractSerializerDemos
{
    [DataContract(Name="OrderBill")]
    public class Bill
    {
        //省略成员
    }
}

所以我们可以采用一种动态的设置方式，为数据契约的名称指定一个模板，使用表示泛型数据契约名称和泛型类型哈希值的占位符。其中{0}、{1}表示的是范型数据契约的名称，数字表示相应的范型参数出现的次序，而哈希值则通过{#}表示。所以下面两种范型数据契约是完全等效的。

namespace Artech.DataContractSerializerDemos
{
    [DataContract]
    public class Bill
    {
        //省略成员
    }
}
namespace Artech.DataContractSerializerDemos
{
    DataContract(Name="BillOf{0}{1}{#}")]
    public class Bill
    {
        //省略成员
    }
}

注：部分内容节选自《WCF技术剖析（卷1）》第五章:序列化与数据契约（Serialization and Data Contract）

WCF技术剖析系列：

作者：

出处：

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。