上一節(jié)我們學(xué)習(xí)了WCF分布式開發(fā)步步為贏(5)服務(wù)契約與操作重載部分。今天我們來(lái)繼續(xù)學(xué)習(xí)WCF服務(wù)契約繼承和服務(wù)分解設(shè)計(jì)相關(guān)的知識(shí)點(diǎn)。WCF服務(wù)契約繼承有何優(yōu)勢(shì)和缺點(diǎn)？實(shí)際項(xiàng)目里契約設(shè)計(jì)有什么原則和依據(jù)？面向?qū)ο蟮脑O(shè)計(jì)經(jīng)驗(yàn)有何值得借鑒的地方？這里我們會(huì)一一給出詳細(xì)的介紹。本文首先介紹的是WCF服務(wù)中契約繼承的一些概念、例子代碼分析，其次來(lái)講解服務(wù)契約的設(shè)計(jì)問(wèn)題。首先介紹的也是進(jìn)行服務(wù)設(shè)計(jì)的必要性，服務(wù)設(shè)計(jì)的原則，示例代碼分析。最后是全文的總結(jié)部分。結(jié)構(gòu)如下：【1】OO面向?qū)ο笤O(shè)計(jì)原則，【2】服務(wù)契約繼承，【3】服務(wù)契約分解概念，【4】服務(wù)契約分解原則，【5】服務(wù)契約分解代碼分析，【6】總結(jié)。

　　【1】面向?qū)ο笤O(shè)計(jì)原則OO：

　　 這里我們有必要先回顧一下面向?qū)ο蟮慕?jīng)典的設(shè)計(jì)原則。這些設(shè)計(jì)原則對(duì)我們WCF服務(wù)契約的設(shè)計(jì)來(lái)說(shuō)有重要的參考價(jià)值。服務(wù)契約實(shí)際利用了接口來(lái)定義實(shí)現(xiàn)，語(yǔ)法類似，WCF框架也是基于現(xiàn)有的語(yǔ)言體系，對(duì)此擴(kuò)展了編程模型，比如增加了屬性設(shè)置機(jī)制等。如果你曾經(jīng)接觸過(guò)OO面向?qū)ο蟮倪@些概念，那么這些設(shè)計(jì)原則理解起來(lái)不會(huì)困難。很多編程書籍里都會(huì)有介紹，設(shè)計(jì)模式相關(guān)書籍里會(huì)有比較詳細(xì)的介紹。這里介紹幾個(gè)主要的概念，為下文的繼承和設(shè)計(jì)WCF服務(wù)契約部分作鋪墊：

　　<1>單一職責(zé)原則（SRP）： 一個(gè)類應(yīng)該僅有一個(gè)引起它變化的原因。

　　<2>開放封閉原則（OCP）： 類模塊應(yīng)該是可擴(kuò)展的，但是不可修改（對(duì)擴(kuò)展開放，對(duì)更改封閉）。

　　<3>Liskov 替換原則（LSP）： 子類必須能夠替換它們的基類。

　　<4> 依賴倒置原則（DIP）： 高層模塊不應(yīng)該依賴于低層模塊，二者都應(yīng)該依賴于抽象。 抽象不應(yīng)該依賴于實(shí)現(xiàn)細(xì)節(jié)，實(shí)現(xiàn)細(xì)節(jié)應(yīng)該依賴于抽象。

　　<5>接口隔離原則（ISP）： 不應(yīng)該強(qiáng)迫客戶程序依賴于它們不用的方法。

　　【2】服務(wù)契約繼承：

　　服務(wù)契約的定義和接口定義類似，接口可以繼承與多個(gè)接口。但是WCF契約屬性是不支持繼承的。由于WCF框架自身的問(wèn)題，不支持契約屬性的繼承，因此這給我們服務(wù)契約屬性的聲明和使用卻有不少限制。在使用契約繼承屬性的過(guò)程中腰注意服務(wù)端契約的屬性繼承問(wèn)題，此外就是客戶端添加服務(wù)引用后，無(wú)法還原服務(wù)端契約層級(jí)的關(guān)系，所有的操作契約由一個(gè)契約類封裝。因此實(shí)際編程我們要兼顧到兩個(gè)方面的情況。

　　【2.1】服務(wù)端契約層級(jí)：

接口支持繼承。但ServiceContract特性不支持繼承的，我們查看其實(shí)現(xiàn)代碼可以知道Inherited = false，即不支持繼承，部分代碼如下：

 ServiceContractAttribute : Attribute
    {
        
    }

　　【3】服務(wù)契約分解概念：

     下面我們繼續(xù)講解服務(wù)契約設(shè)計(jì)的一些概念知識(shí)。其實(shí)服務(wù)契約的設(shè)計(jì)在WCF分布式應(yīng)用項(xiàng)目中屬于比較重要的部分。服務(wù)契約的設(shè)計(jì)和實(shí)現(xiàn)相對(duì)來(lái)多比較復(fù)雜，除了注意已有的設(shè)計(jì)原則之外還要注意WCF契約相關(guān)的特性。面向服務(wù)分析與設(shè)計(jì)的屬于一個(gè)較新的領(lǐng)域。實(shí)際的服務(wù)分析和設(shè)計(jì)我們還是借助于已有的經(jīng)驗(yàn)和原則，來(lái)指我們更好地設(shè)計(jì)服務(wù)契約。這也是本節(jié)給出一個(gè)面向?qū)ο笾匾O(shè)計(jì)原則的原因。

因?yàn)閃CF服務(wù)契約的定義借助現(xiàn)有的編程語(yǔ)言如C#，契約設(shè)計(jì)實(shí)際首先就是對(duì)服務(wù)接口的設(shè)計(jì)。我們應(yīng)該如何設(shè)計(jì)服務(wù)接口？如何知道服務(wù)接口中應(yīng)該定義哪些操作？每個(gè)接口又應(yīng)該包含多少操作？等等都是我們必須考慮的問(wèn)題。Service Contract Factoring就是要考慮服務(wù)接口的分解問(wèn)題。在面向服務(wù)的應(yīng)用程序中，可重用的基本單元就是服務(wù)接口。因此如何設(shè)計(jì)服務(wù)接口就是重中之重。

　　【4】服務(wù)契約分解原則：

這里我們?cè)O(shè)計(jì)服務(wù)接口時(shí)候即遵循單一職責(zé)和接口隔離等原則，又要考慮系統(tǒng)的開發(fā)成本。合理的接口是專業(yè)的、松耦合的、規(guī)則化和可重用的接口。這些優(yōu)勢(shì)同樣有利于整個(gè)系統(tǒng)的松耦合和可重用等特性。總的來(lái)說(shuō)，契約分解的目的就是使接口包含的更少操作。

如果我們定義了太多的細(xì)粒度服務(wù)接口，雖然它們易于實(shí)現(xiàn)，但集成它們的代價(jià)太高。如果我們僅定義了一個(gè)復(fù)雜的服務(wù)接口，雖然集成的成本會(huì)降低，但卻接口的實(shí)現(xiàn)和可維護(hù)性較差。我們?cè)O(shè)計(jì)面向服務(wù)的系統(tǒng)時(shí)，需要平衡兩個(gè)影響系統(tǒng)的因素，接口成本和集成成本。參見(jiàn)下圖。

　　【5】服務(wù)契約分解代碼分析：

這里我們來(lái)講解一個(gè)簡(jiǎn)單的服務(wù)契約設(shè)計(jì)的例子。這里我們還繼續(xù)使用交通車為例子進(jìn)行講解。

我們首先定義一個(gè)接口交通工具IVehicle，定義了如下：

NET技術(shù)：WCF分布式開發(fā)步步為贏系列的(6)：WCF服務(wù)契約繼承與分解設(shè)計(jì)，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。