您的位置:知识库 » .NET技术

WCF分布式开发步步为赢系列的(6):WCF服务契约继承与分解设计

作者: Frank Xu Lei  来源: 博客园  发布时间: 2009-04-10 10:34  阅读: 4829 次  推荐: 0   原文链接   [收藏]  
摘要:本文介绍了WCF服务契约继承有何优势和缺点以及实际项目里契约设计有什么原则和依据和面向对象的设计经验有何值得借鉴的地方
[1] 面向对象设计原则OO
[2] 服务契约继承
[3] 服务契约分解概念
[4] 服务契约分解代码分析

  上一节我们学习了WCF分布式开发步步为赢(5)服务契约与操作重载部分。今天我们来继续学习WCF服务契约继承和服务分解设计相关的知识点。WCF服务契约继承有何优势和缺点?实际项目里契约设计有什么原则和依据?面向对象的设计经验有何值得借鉴的地方?这里我们会一一给出详细的介绍。本文首先介绍的是WCF服务中契约继承的一些概念、例子代码分析,其次来讲解服务契约的设计问题。首先介绍的也是进行服务设计的必要性,服务设计的原则,示例代码分析。最后是全文的总结部分。结构如下:【1】OO面向对象设计原则,【2】服务契约继承,【3】服务契约分解概念,【4】服务契约分解原则,【5】服务契约分解代码分析,【6】总结。

  【1】面向对象设计原则OO:

   这里我们有必要先回顾一下面向对象的经典的设计原则。这些设计原则对我们WCF服务契约的设计来说有重要的参考价值。服务契约实际利用了接口来定义实现,语法类似,WCF框架也是基于现有的语言体系,对此扩展了编程模型,比如增加了属性设置机制等。如果你曾经接触过OO面向对象的这些概念,那么这些设计原则理解起来不会困难。很多编程书籍里都会有介绍,设计模式相关书籍里会有比较详细的介绍。这里介绍几个主要的概念,为下文的继承和设计WCF服务契约部分作铺垫:

  <1>单一职责原则(SRP): 一个类应该仅有一个引起它变化的原因。

  <2>开放封闭原则(OCP): 类模块应该是可扩展的,但是不可修改(对扩展开放,对更改封闭)。

  <3>Liskov 替换原则(LSP): 子类必须能够替换它们的基类。

  <4> 依赖倒置原则(DIP): 高层模块不应该依赖于低层模块,二者都应该依赖于抽象。 抽象不应该依赖于实现细节,实现细节应该依赖于抽象。

  <5>接口隔离原则(ISP): 不应该强迫客户程序依赖于它们不用的方法。

0
0
 
标签:WCF

.NET技术热门文章

    .NET技术最新文章

      最新新闻

        热门新闻