知识大全 Data Contract概览

Posted 2022-07-14 厂商

篇首语：青春须早为，岂能长少年。本文由小常识网(cha138.com)小编为大家整理，主要介绍了知识大全 Data Contract概览相关的知识，希望对你有一定的参考价值。

WCF中的Data Contract：Data Contract概览 以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！

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

　　这实际上体现了两者相互交互的问题在一个分布式的环境中要实现两者的交互有两个必须要解决的问题如何保证Service的使用者对Service的调用能够被Service端理解以及对Service的调用如何抵达Service Side 后者实质上是关于munication的问题我们现在不去谈它第一个问题就是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 Fet的形式来异步地调用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 Fet的模式）和Message本身具有的格式

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

　　概括的说 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= )]public class Order [DataMember(Order = )]public Guid OrderIDget;set;

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

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

　　就可以转变成另一种厂商中立的以XSD表示的Neutral Data Contract

　　 xmlns:xs=

　　xmlns:tns= xmlns:ser= > namespace="" />

[System.Runtime.Serialization.DataContractAttribute(Name="Order", Namespace="

　　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="")]public class Order [DataMember(Order = 0)]public Guid OrderIDget;set;

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

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

　　XSD：

　　 xmlns:xs="" xmlns:tns=""xmlns:ser=""> namespace="" />

　　 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相匹配。 cha138/Article/program/net/201311/13263