WCF服务契约的重载与继承详解

本章主要介绍WCF服务契约的重载与继承，以及设计和分离服务契约的一般原则。

2. 服务契约重载

　　基于 WSDL 的操作不支持操作重载，但可以使用 OperationContract 特性的 Name 属性，为操作指定别名，手动地启用操作重载。

?
　　客户端导入契约并生成代理时，导入的操作就会包含定义的别名，也可以在客户端使用导入契约的 Name 属性，指定别名并重载方法，使它与导入的操作名保持一致。

?
3. 服务契约的继承

　　服务契约接口支持继承功能，我们定义一个契约层级，Human为第一级，Man和Woman分别继承Huamn，如下：

?
　　在WCF中，一个契约对应一个服务，一个服务对应一个宿主，一个宿主对应多个终结点。上例中定义了三个契约，所以可为每一个契约实现一个服务。在WCF服务契约层级关系中，一个服务类能实现整个契约层级。

?
　　客户端服务契约的定义，既可以用取消契约层级的方式实现，也可以用恢复契约层级的方式实现。取消契约层级的方式使用 OperationContract 特性中的 Action 与 ResponseAction 属性，使导入的接口定义保留原来定义每个操作的契约名。

?
　　使用恢复契约层级的方式，如下所示：

?
4. 客户端服务契约代理链(Proxy Chaining)

　　如果服务契约层级过多，在客户端实现服务契约层级就会显得冗余且复杂，可以使用服务契约代理链(Proxy Chaining)来解决该问题。服务契约代理链为代理建立了 IS-A 关系(继承关系)，保证了代码的重用。实现方法：将最顶层的基契约代理直接继承于ClientBase<T>，T为最底层的子接口类型。所有的其他代理则直接继承于它们的上一级代理，同时实现各自的契约接口。

?
5. 设计和分离服务契约的一般原则

　　一个服务契约是逻辑相关的操作的组合。所谓的“逻辑相关”通常指特定的领域逻辑。我们可以将服务契约想象成实体的不同表现。在需求分析之后，一旦识别出实体支持的所有操作，就需要将它们分配给契约。这称为服务契约的分解（Service Contract Factoring）。分解服务契约时，通常需要考虑可重用元素（Reusable Element）。在面向服务的应用程序中，一个可重用的基本单元就是服务契约。合理的契约分解可以实现深度特化、松散耦合、精细调整以及契约的重用。这些优势有助于改善整个系统。总的来说，契约分解的目的就是使契约包含的操作尽可能少。

　　设计面向服务的系统时，需要平衡两个影响系统的因素。一个是实现服务契约的代价，一个则是将服务契约合并或集成为一个高内聚应用程序的代价。如果我们定义了太多的细粒度服务契约，虽然它们易于实现，但集成它们的代价未免太高。另一方面，如果我们仅定义了几个复杂而又庞大的服务契约，虽然集成的代价可能会降低，但却制约了契约的实现。如下图所示：



总结服务契约分解的规则和方法如下：

避免设计只具有一个操作的服务契约。一个服务契约体现了实体的特征，如果服务只有一个操作，则过于单调，没有实际的意义。此时，就应该检查它是否使用了太多的参数？它的粒度是否过粗，因此需要分解为多个操作？是否需要将该操作转移到已有的服务契约中？
服务契约成员的最佳数量应介于 3 到 5 之间。如果设计的服务契约包含了多个操作，例如 6 到 9 个，仍然可能工作良好。但是，我们需要判断这些操作是否会因为过度分解而需要合并。如果服务契约定义了 12 个甚至更多的操作，毫无疑问，我们需要将这些操作分解到单独的服务契约中，或者为它们建立契约层级。
避免定义准属性操作（Property -Like Operation）

?
服务契约允许客户端在调用抽象操作时，不用关心具体的实现细节。准属性操作由于无法封装状态的管理，因此在封装性的表现上差强人意。在服务端，我们可以封装读写变量值的业务逻辑，但在理想状态下，我们却不应该干涉客户端对属性的使用。客户端应该只负责调用操作，而由服务去管理服务对象的状态。这种交互方式应该被表示为 DoSomething()样式。

1. 源码下载

WCF服务契约重载：http://files.cnblogs.com/tianzhiliang/WCF.Chapter2.Overloading.rar
WCF服务契约继承：http://files.cnblogs.com/tianzhiliang/WCF.Chapter2.InheritanceReworked.rar
WCF服务契约代理链：http://files.cnblogs.com/tianzhiliang/WCF.Chapter2.InheritanceProxyChaining.rar