WCF分布式开发步步为赢系列的(6)：WCF服务契约继承与分解设计
[2] 服务契约继承
[3] 服务契约分解概念
[4] 服务契约分解代码分析
【5】服务契约分解代码分析：
这里我们来讲解一个简单的服务契约设计的例子。这里我们还继续使用交通车为例子进行讲解。
我们首先定义一个接口交通工具IVehicle，定义了如下：
interface IVehicle
{
//操作契约,跑，开的契约
[OperationContract]
string Run();
//操作契约,拉人、载人的契约
[OperationContract]
string Take();
//操作契约,运输货物的契约
[OperationContract]
string Carry();
}
这里的交通工具接口，分别定义了跑，拉人和载货三种操作。放在一个接口中。这就违反了接口设计中的主要的原则ISP接口隔离原则。我们不应该强迫服务继承他们不需要的操作。接口隔离原则ISP：使用多个专门的接口比使用单一的接口要好。从服务设计的角度来说：一个类对另外一个类的依赖性应当是建立在最小的接口上的。如果服务类只需要某一些方法的话，那么就应服务类可以继承相应的接口实现这些需要的方法，而不要实现不需要的方法。继承接口意味着作出承诺，服务类必须实现，也就是所谓的契约的概念。
因此，我们将服务契约分解为接口层级的方式，通过接口分解和继承，实现操作的分离。这里可以重新定义两个接口货车ITruck和小轿车ICar，分别定义自己的拉货Carry();和载人Take()的操作，当服务类需要实现拉货操作的时候就继承避免了接口设计的职责的混淆。代码如下：
[ServiceContract(Namespace = "http://www.cnblogs.com/frank_xl/")]
interface IVehicle
{
//操作契约,跑，开的契约
[OperationContract]
string Run();
}
//接口继承关系不支持ServiceContract继承
[ServiceContract(Namespace = "http://www.cnblogs.com/frank_xl/")]
interface ITruck : IVehicle
{
//操作契约,运输货物的契约
[OperationContract]
string Carry();
}
//接口继承关系不支持ServiceContract继承
[ServiceContract(Namespace = "http://www.cnblogs.com/frank_xl/")]
interface ICar : IVehicle
{
//操作契约,拉人、载人的契约
[OperationContract]
string Take();
}
【6】总结：
以上就是对WCF服务继承和分解设计相关知识的介绍，下面简要做下介绍：
<1>:本文开始讲解了OO面向对象的设计原则，作为经典的面相对象的设计经验，也是设计模式文章里的重要的知识点，对WCF服务设计有主要的参考价值，比如SRP单一职责、ISP接口隔离等原则；
<2>:我们应该避免设计过多或者过少的接口，应该考虑系统的服务接口定义实现的复杂度和系统服务集成的成本。综合起来权衡，取得一个平衡点。服务契约成员的最佳数量（根据经验总结，仅代表本人观点）应介于3到5之间。开发者在制订WCF编码规范时，应该指定一个上限值（例如20）。无论在何种情况，都不能超过该值。
另外避免定义类属性操作（Property-Like Operation）这样的定义十分类似C#的属性访问器，例如：
string GetCarNumber();
我们不应该干涉客户端属性访问，客户端在调用抽象操作时，不用关心具体的实现细节，只负责调用操作，而由服务去管理服务对象的状态。
<3>:WCF服务设计原则只是一些参考原则，对实际的开发工作起知道作用。包括前面叙述的面相对象的经典的设计原则和设计模式的宝贵经验。实际项目中需要结合自身的实际情况，实时调整和设计服务契约接口的设计，以期设计去更加合理和高效的服务契约。最后是本文的参考代码：Files/frank_xl/WCFServiceFactoringFrankXuLei.rar，下一节我们继续学习WCF数据契约的知识，请继续关注~。
