谈谈WCF中的Data Contract （1）：Data Contract Overview

 Contract in SO：Contract是对操做和数据的抽象

在咱们看来，Service Orientation提供了一种对业务、功能进行分解的方式。针对SO，咱们把一个具体的业务流程或者一个复杂的功能分解成一个个独立完成某项任务的子单元，这些子单元经过一个个Service来承载。对于Service自己来说，他们应该是自治的，独自完成本身的功能、不依赖于其余的Service。可是Service的价值体如今它被潜在的消费者使用的程度。这实际上包含两方面的内容，做为Service自己，它如何将本身暴露出来，供一切可能的潜在用户调用，这些潜在用户不只仅指那些不一样的Client，也包含其余的Service：Service Orientation其中一个特征就是“Service should be composite”,鼓励将一个个相关细粒度的Service组合成一个大的Service。这样有利于较大限度的实现重用，而重用每每意味着更小的投入、更佳的可维护性。而另外一方面就是这些消费者经过怎样的方式来调用它所须要的Service。

这实际上体现了二者相互交互的问题。在一个分布式的环境中要实现二者的交互，有两个必需要解决的问题：如何保证Service的使用者对Service的调用可以被Service端理解，以及对Service的调用如何抵达Service Side。后者实质上是关于communication的问题，咱们如今不去谈它。第一个问题就是Contract须要解决的问题。

咱们知道SOA一个主要的目标就是促进不一样技术平台的互操做，要真正实现这样一个宏伟的目标是一件极不容易的事情，须要不一样的厂商和标准组织相互协做，制定一个你们一致遵循的标准。这样一个标准就是WS-* 。咱们很清楚，不管个个厂商各自的标准怎样千差万别，可是有个标准是他们必需要遵循的，那就是Internet的标准，若是哪家公司拒绝Internet，那确定要被淘汰的。而对于Internet，基于Http的网络协议和基于XML的数据表达已经成为了事实上的标准。对于SOA来讲，XML不只仅用于表示Service调用携带的数据（参数和返回值），更用于表示这个调用自己，以及知足各类要求的控制信息, 好比基于Security、Session、Reliable Messaging、Transaction等等的控制信息。WS-*就是一个基于XML的标准。而对于SOA中的Contract所要作的就是寻求一种厂商中立的方式来表示Service的接口、和用于交互的数据结构。前者就是Service Contract、后者就是Data Contract。

SOA中的一个Service由一组相关的Operation来构成。Service Contract用于表示构成该Service全部Operation的Interface（而不是Implementation）。说得更加具体点，你们都知道Consumer和Service之间的交互都是经过Message的形式来实现的，一次交互就是一次Message Exchange。在不一样的场景，咱们以不经过Pattern来进程Message Exchange，好比咱们一般使用Request-Response的方式来向Service发送Request进而获得返回结果，咱们也能够以Request-Forget的形式来异步地调用Service（不须要从Service获取Response），咱们可让一个Service在没有收到任何Request的状况下，以广播的形式向注册的Client发送通知，固然咱们还有其余不一样的消息交互的模式，咱们把这些不一样的信息交互方式称为MEP（Message Exchange Pattern）。也就是说，一个Operation最终经过被最终转换成了按照某种MEP进行的消息交互，而Service Contract旨在实现对这种MEP的描述，好比是否须要Request Message或者Response Message（若是仅仅有Response Message就是Notification的方式；若是仅仅具备Request Message,那就是咱们上面谈到的Request-Forget的模式），和Message自己具备的格式。

上面咱们说了Service Contract是以一种厂商中立的形式描述体现为某种模式的消极交互、构成整个Service的全部Operation。而咱们也说了Consumer和Service的交互本质上看就是按照某种Pattern体现的一次Message Exchange，好像具备了Service Contract的描述就能够了。可是实际上，单单有了Service Contract对Service的描述还不够，由于Service Contract自己缺少对携带于Message，用于信息传递的数据类型的描述，而这是Data Contract须要解决的问题。咱们知道不一样的技术平台对数据类型的表示是不同的，可能某一种技术平台使用16bit来表述一个浮点数，另外一种则使用32bit。因此要想实现不一样技术平台的互操做，将不一样技术平台同一类型的数据以一种厂商中立的形式来描述是必须的。

归纳的说，SOA中的Service Contract和Data Contract就是一种厂商中立的数据呈现方式对Service Interface和Data Type的。而Service的调用都是经过SOAP Message来实现，SOAP是基于XML，而对于XML结构的定义，咱们很天然地想到XSD，咱们可简单地将SOA中的Contract当作是一个XSD。

Contract in WCF

上面咱们其实是在一个厂商中立的前提下探讨Contract，这里的Contract和具体的平台和技术无关。接下来咱们要谈的是基于技术的话题：讨论一下WCF下的Contract。简单地说，WCF中的Contract主要的功能就是如何将一个基于.NET的CLR Type，Interface或者Class，转化成一个咱们上面提到的Neutral Contract。好比，若是咱们在一个Interface和它的成员上分别运用Service Contract Attribute和Operation Contract，当咱们Host实现了该Interface的Service的时候，WCF就能将在一个.NET-specific的CLR Type暴露成一个Neutral Service Contract。同理对于一个，咱们经过在一个Class和它的成员上分别添加DataContractAttribute和DataMemberAttribute，就能够就该CLR Type转变成Neutral Data Contract。

好比咱们一个运用了DataContractAttribute和DataMemberAttribute的Order class：

namespace Artech.DataContractVersioning.Service
{
    [DataContract(Namespace="http://artech.datacontractversioning")]
    public class Order
    {
        [DataMember(Order = 0)]
        public Guid OrderID
        {get;set;}

        [DataMember(Order = 1)]
        public DateTime OrderDate
        { get; set; }

        [DataMember(Order = 2)]
        public Guid SupplierID
        { get; set; }
    }
}

就能够转变成另外一种厂商中立的、以XSD表示的Neutral Data Contract：

<? xml version="1.0" encoding="utf-8" ?>
< xs:schema elementFormDefault ="qualified" targetNamespace ="http://artech.datacontractversioning"
    xmlns:xs ="http://www.w3.org/2001/XMLSchema" xmlns:tns ="http://artech.datacontractversioning"
    xmlns:ser ="http://schemas.microsoft.com/2003/10/Serialization/" >
< xs:import schemaLocation ="http://artech/Artech.DataContractVersioning/OrderManagerService.svc?xsd=xsd1"
    namespace ="http://schemas.microsoft.com/2003/10/Serialization/" />
< xs:complexType name ="Order" >
    < xs:sequence >
        < xs:element minOccurs ="0" name ="OrderID" type ="ser:guid" />
        < xs:element minOccurs ="0" name ="OrderDate" type ="xs:dateTime" />
        < xs:element minOccurs ="0" name ="SupplierID" type ="ser:guid" />
    </ xs:sequence >
</ xs:complexType >< xs:element name ="Order" nillable ="true" type ="tns:Order" /></ xs:schema >

当Client须要调用该Order type的Service的时候，在本地须要一个Data Type可以匹配上面的以XSD体现的Data Contract。通常地，咱们能够在VS中经过Add Service Reference的方式或者经过一些Tools，好比XSDUtil和SvcUtil来生成这样的Class。好比咱们经过Add Service Reference方式，就能够生成下面一个对应的Order class:

[System.Diagnostics.DebuggerStepThroughAttribute()]
    [System.CodeDom.Compiler.GeneratedCodeAttribute( " System.Runtime.Serialization " , " 3.0.0.0 " )]
    [System.Runtime.Serialization.DataContractAttribute(Name = " Order " , Namespace = " http://artech.datacontractversioning " )]
    [System.SerializableAttribute()]
    public partial class Order : object , System.Runtime.Serialization.IExtensibleDataObject, System.ComponentModel.INotifyPropertyChanged {
       
        [System.NonSerializedAttribute()]
        private System.Runtime.Serialization.ExtensionDataObject extensionDataField;
       
        [System.Runtime.Serialization.OptionalFieldAttribute()]
        private System.Guid OrderIDField;
       
        [System.Runtime.Serialization.OptionalFieldAttribute()]
        private System.DateTime OrderDateField;
       
        [System.Runtime.Serialization.OptionalFieldAttribute()]
        private System.Guid SupplierIDField;
       
        [global::System.ComponentModel.BrowsableAttribute(false)]
        public System.Runtime.Serialization.ExtensionDataObject ExtensionData {
            get {
                return this.extensionDataField;
            }
            set {
                this.extensionDataField = value;
            }
        }
       
        [System.Runtime.Serialization.DataMemberAttribute()]
        public System.Guid OrderID {
            get {
                return this.OrderIDField;
            }
            set {
                if ((this.OrderIDField.Equals(value) != true)) {
                    this.OrderIDField = value;
                    this.RaisePropertyChanged("OrderID");
                }
            }
        }
       
        [System.Runtime.Serialization.DataMemberAttribute(Order=1)]
        public System.DateTime OrderDate {
            get {
                return this.OrderDateField;
            }
            set {
                if ((this.OrderDateField.Equals(value) != true)) {
                    this.OrderDateField = value;
                    this.RaisePropertyChanged("OrderDate");
                }
            }
        }
       
        [System.Runtime.Serialization.DataMemberAttribute(Order=2)]
        public System.Guid SupplierID {
            get {
                return this.SupplierIDField;
            }
            set {
                if ((this.SupplierIDField.Equals(value) != true)) {
                    this.SupplierIDField = value;
                    this.RaisePropertyChanged("SupplierID");
                }
            }
        }
       
        public event System.ComponentModel.PropertyChangedEventHandler PropertyChanged;
       
        protected void RaisePropertyChanged(string propertyName) {
            System.ComponentModel.PropertyChangedEventHandler propertyChanged = this.PropertyChanged;
            if ((propertyChanged != null)) {
                propertyChanged(this, new System.ComponentModel.PropertyChangedEventArgs(propertyName));
            }
        }
    }

经过上面这样一个在Client自动生成的Order class，你就能够建立Order对象来调用相应的Service了。这种自动生成代码的方式确实很省事，并且当Service端的Data Contract改变的时候，你只须要Update Service Reference就能够从新生成并覆盖现有的代码。可是，就我我的来讲，我不要喜欢使用这样的方式，若是对Service暴露出来的数据结构很熟悉的话，我宁愿本身编写这样的class。特别地，对于WCF-WCF（Client和Service都是WCF），若是可能的话，让定义Contract的Assembly在Service和contract共享，我想是最直接的方式。

上面咱们说所说的都是根据Service暴露出来的、以厂商中立方式体现的（好比XSD）Client端生成或者自行建立与之相对的Data type。可是对于下面这样的场景，重建Data Type却不是一个好的选择：Client如今已经有一个Order class，并且不少的业务逻辑均依赖于这个class，如今须要调用一个现有的Order Processing Service对Order做某种处理，可是Service 的Order Type，说得更准确地，Service暴露出来的Order Data Contract和Client现有的Order class不太一致，很显然在这种状况下，Client端部可能使用本地Order对象来调用该Service，由于Client提供的数据不符合该Data Contract，若是想上面讲到了从新生成或者建立一个新的Order class，就意味着其余依赖于现有Order class的业务逻辑均会受其影响。因此，在这里，咱们须要WCF Data Contract提供给咱们的另外一种功能——适配功能：经过现有的CLR Type上添加或者改变DataContractAttribute 或者DataMemberAttribute的参数来使现有的CLR Type符合一个既定的Data Contract。究其本质，不管将CLR Type暴露成一个Neutral Contract也好，将CLR Type与既定的Neutral Contract进行适配也罢，这两种功能都是等效的。

接下来，咱们就根据一个例子来讨论WCF Data Contract如何将一个现有的CLR Type与一个既定的Neutral Data Contract匹配。

Data Contract Mapping Mechanism

经过上面的介绍，咱们发现WCF Data Contract就如同一个适配器，弥合了 CLR Type和Neutral Contract的差别，很容易地实现了他们之间的匹配。接下来，咱们就以一个实际的例子来介绍WCF DataContract的这种适配功能：经过DataContractAttribute的修饰，实现了将一个现有Data Type向一个既定的Neutral Data Contract进行适配，从而实现了对基于该Neutral Data Contract的Service 进行正常调用的目的。

咱们就以上面提到的Order Class为例，Service端的Order class最终暴露成一个以XSD表示的Neutral Contract：

Order class：

namespace Artech.DataContractVersioning.Service
{
    [DataContract(Namespace="http://artech.datacontractversioning")]
    public class Order
    {
        [DataMember(Order = 0)]
        public Guid OrderID
        {get;set;}

        [DataMember(Order = 1)]
        public DateTime OrderDate
        { get; set; }

        [DataMember(Order = 2)]
        public Guid SupplierID
        { get; set; }
    }
}

XSD：

<? xml version="1.0" encoding="utf-8" ?>
< xs:schema elementFormDefault ="qualified" targetNamespace ="http://artech.datacontractversioning"
    xmlns:xs ="http://www.w3.org/2001/XMLSchema" xmlns:tns ="http://artech.datacontractversioning"
    xmlns:ser ="http://schemas.microsoft.com/2003/10/Serialization/" >
< xs:import schemaLocation ="http://artech/Artech.DataContractVersioning/OrderManagerService.svc?xsd=xsd1"
    namespace ="http://schemas.microsoft.com/2003/10/Serialization/" />
< xs:complexType name ="Order" >
    < xs:sequence >
        < xs:element minOccurs ="0" name ="OrderID" type ="ser:guid" />
        < xs:element minOccurs ="0" name ="OrderDate" type ="xs:dateTime" />
        < xs:element minOccurs ="0" name ="SupplierID" type ="ser:guid" />
    </ xs:sequence >
</ xs:complexType >< xs:element name ="Order" nillable ="true" type ="tns:Order" /></ xs:schema >

设咱们在Client有一个与之结构类似的CustomOrder class：

public class CustomOrder
    {
        public Guid OrderNo
        { get; set; }

        public Guid SupplierNo
        { get; set; }

        public DateTime OrderDate
        { get; set; }
}

仔细分析CustomOrder和Service的Order以及XSD，咱们发现二者除告终构同样以外，没有一处使相同的，具体体如今：         

• Class Name 不同。
  
• NameSpace 不同， Order 和 XSD 的 namespace 为 http://artech.datacontractversioning ，而 CustomOrder 却没有显示指定一个 Namespace （这样 WCF 会为其指定一个默认的 namespace ）。
  
• 成员的名称不同。
  
• 成员的顺利不同。

若是咱们如今要使咱们的CustomOrder知足现有的Order Data Contract，咱们就须要消除这些不一样之处，经过DataContractAttribute和DataMemberAttribute，这样的问题根本就不是问题，下面就是咱们从新定义的CustomOrder class。

  [DataContract(Name = " Order " ,Namespace = " http://artech.datacontractversioning " )]
    public class CustomOrder
    {
        [DataMember(Order = 0, Name="OrderID")]
        public Guid OrderNo
        { get; set; }

        [DataMember(Order = 2, Name = "SupplierID")]
        public Guid SupplierNo
        { get; set; }

        [DataMember(Order = 1)]
        public DateTime OrderDate
        { get; set; }

        [DataMember(Order = 3)]
        public string ShippingAddress
        { get; set; }
}

经过在DataContractAttribute指定Name和Namespace使Data Contract和Namespace和既定的Contract相匹配，经过DataMemberAttribute的Name和Order参数是成员的名称和次序与既定的Contract相匹配。

[原创]谈谈WCF中的Data Contract（1）：Data Contract Overview
[原创]谈谈WCF中的Data Contract（2）：WCF Data Contract对Generic的支持
[原创]谈谈WCF中的Data Contract（3）：WCF Data Contract对Collection & Dictionary的支持
[原创]谈谈WCF中的Data Contract（4）：WCF Data Contract Versioning