《WCF按部就班学习系列2_WCF服务契约概述》

 

本文的主要结构为：1)WCF服务契约的概述2)服务契约的分解与设计 3)实现代码分析及运行结果4)源码下载5)下一篇计划6)参考说明

 

(1)WCF服务契约的概述(What)

  1.1契约：WCF的所有服务都会公开为契约（Contract）。契约与平台无关，是描述服务功能的标准方式。WCF定义了四种类型的契约：服务契约（Service        Contract），数据契约（Data Contract），错误契约（Fault Contract），消息契约（Message Contract）。

  1.2服务契约（Service Contract）：服务契约描述了客户端能够执行的服务操作。

  1.3ServiceContract特性可以将一个CLR接口映射为与技术无关的服务契约。ServiceContract特性公开了CLR接口（或者类）作为WCF契约。WCF契约与类型的访问限定无关，因为类型的访问限定属于CLR的概念。即使将ServiceContract特性应用在内部（Internal）接口上，该接口同样会公开为公有服务契约，以便于跨越服务边界实现服务的调用。如果接口没有标记ServiceContract特性，WCF客户端则无法访问它（即使接口是公有的）。这一特点遵循了面向服务的一个原则，即明确的服务边界。为满足这一原则，所有契约必须明确要求：只有接口（或者类）可以被标记为ServiceContract特性，从而被定义为WCF服务，其他类型都不允许。

  1.4WCF只允许将OperationContract特性应用到方法上，而不允许应用到同样属于CLR概念的属性、索引器和事件上。WCF只能识别作为逻辑功能的操作（Operation）。通过应用OperationContract特性，可以将契约方法暴露为逻辑操作，使其成为服务契约的一部分。接口（或类）中的其他方法如果没有应用OperationContract特性，则与契约无关。这有利于确保明确的服务边界，为操作自身维护一个明确参与（Opt-In）的模型。此外，契约操作不能使用引用对象作为参数，只允许使用基本类型或数据契约。应用ServiceContract特性WCF允许将ServiceContract特性应用到接口或类上。当接口应用了Service-Contract特性后，需要定义类实现该接口。

  1.5可以为契约定义命名空间。契约的命名空间具有与.NET编程相同的目的：确定契约的类型范围，以降低类型的冲突几率.可以使用ServiceContract类型的Namespace属性设置命名空间：

 [ServiceContract(Namespace = "MyNamespace")]

 interface IMyContract

 {...}

若非特别指定，契约的默认命名空间为http://tempuri.org。对外服务的命名空间通常使用公司的URL；至于企业网（Intranet）内部服务的命名空间，则可以定义有意义的唯一名称，例如MyApplication。

  1.6 在默认情况下，契约公开的名称就是接口名。但是也可以使用ServiceContract特性的Name属性为契约定义别名，从而在客户端的元数据（Metadata）中公开不同的名称：

 [ServiceContract(Name = "IMyContract")]

 interface IMyOtherContract

 {...}

  1.7相似的，操作公开的名称默认为方法名，但我们同样可以使用OperationContract特性的Name属性设置别名，从而公开不同的操作名：

    [ServiceContract]

    interface IMyContract

    {

    [OperationContract(Name = "SomeOperation")]

    void MyMethod(string text);

    }

(2)服务契约的分解与设计

  2.1契约分解

一个服务契约是逻辑相关的操作的组合。所谓的“逻辑相关”通常指特定的领域逻辑。我们可以将服务契约想象成实体的不同表现。一旦识别（在需求分析之后）出实体支持的所有操作，就需要将它们分配给契约。这称为服务契约的分解。分解服务契约时，通常需要考虑可重用元素（Reusable Element）。在面向服务的应用程序中，一个可重用的基本单元就是服务契约.

  2.2分解准则

显而易见，合理的契约分解可以实现深度特化、松散耦合、精细调整以及契约的重用。这些优势有助于改善整个系统。总的来说，契约分解的目的就是使契约包含的操作尽可能少。

设计面向服务的系统时，需要平衡两个影响系统的因素（参见图2-1 平衡服务的个数与规模）。一个是实现服务契约的代价，一个则是将服务契约合并或集成为一个高内聚应用程序的代价。

2.3总结

对于任何一个系统，实现契约所付出的代价，包括设计服务以及维护服务的代价，等于上述两个因素的总和（实现的代价与集成的代价）。图2-1的一个区域显示了最小代价与服务契约规模和数量之间的关系。一个设计良好的系统，服务的个数与规模应该恰如其分，遵循平衡的“中庸之道”，力求达到“增之一分则太多（大），减之一分则太少（小）”的标准。

(3)实现代码分析及运行结果

 3.1为服务与客户端的操作指定别名。在服务端，要为重载的操作提供唯一的标识名.

using System; using System.ServiceModel; namespace WCFService { //服务契约 [ServiceContract] public interface IMyCalculator { //重载,为操作指定别名 [OperationContract(Name = "AddInt")] int Add(int arg1, int arg2); [OperationContract(Name = "AddDouble")] double Add(double arg1, double arg2); } //定义类实现服务契约重载的方法 public class MyCalculator : IMyCalculator { //Int public int Add(int arg1, int arg2) { return arg1 + arg2; } //Double public double Add(double arg1, double arg2) { return arg1 + arg2; } } }  

3.2使客户端代码支持操作重载。方法是将导入的代理与契约的方法名修改为重载的名称，并确保代理类能够使用重载方法调用内部代理,在客户端使用导入契约的Name属性，指定别名并重载

 

方法，使它与导入的操作名保持一致，

using System; using System.ServiceModel; //服务契约 [ServiceContract] public interface IMyCalculator { [OperationContract(Name = "AddInt")] int Add(int arg1, int arg2); [OperationContract(Name = "AddDouble")] double Add(double arg1, double arg2); } //实现接口定义的方法 public partial class CalculatorClient : ClientBase<IMyCalculator>, IMyCalculator { //构造函数 public CalculatorClient() { } public CalculatorClient(string configurationName) : base(configurationName) { } //客户端实现重载 public int Add(int arg1, int arg2) { return Channel.Add(arg1, arg2); } //客户端实现重载 public double Add(double arg1, double arg2) { return Channel.Add(arg1, arg2); } }  

(4)源码下载

http://download.csdn.net/source/2992039

(5)下一篇计划

下一篇主要介绍数据契约的相关知识。

(6)参考说明

1.《programming in WCF》