一、上章回顧

　　上篇我們主要講解了系統(tǒng)架構(gòu)中的四種架構(gòu)模式，并且分析了四種架構(gòu)模式的實(shí)現(xiàn)及應(yīng)用場(chǎng)景，那么先來(lái)回顧下架構(gòu)中的業(yè)務(wù)邏輯層的使用及總結(jié)。

如果大家對(duì)圖中講述的內(nèi)容不明白或者說(shuō)是不深入那么可以參考上篇講

　　解的內(nèi)容：系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-業(yè)務(wù)邏輯層。

　　二、摘要

　　本文將已架構(gòu)的方式去分析分層結(jié)構(gòu)中的服務(wù)層的設(shè)計(jì)，如何設(shè)計(jì)出來(lái)滿足我們說(shuō)的業(yè)務(wù)需求及設(shè)計(jì)規(guī)范的服務(wù)層將是我們的目標(biāo)，可能我想大家在項(xiàng)目架構(gòu)的

　　過(guò)程中可能有些同仁，沒(méi)有用到該層，或者說(shuō)是采用的是常用的分層結(jié)構(gòu)的設(shè)計(jì)，而沒(méi)有把服務(wù)層單獨(dú)的抽出來(lái)，當(dāng)然我們必須首先知道服務(wù)層是干什么用的？為什么

　　要單獨(dú)寫一個(gè)服務(wù)層呢？還有就是設(shè)計(jì)服務(wù)層我們從哪些方面入手呢？及怎么判定一個(gè)服務(wù)層設(shè)計(jì)的好壞呢？這些都是本章要講解的具體內(nèi)容，當(dāng)然本文中的內(nèi)容都是

　　本人平時(shí)在項(xiàng)目中的一些經(jīng)驗(yàn)，可能在一些有豐富經(jīng)驗(yàn)設(shè)計(jì)的大牛面前，我講解的都是皮毛，但是我抱著能給初學(xué)者指引和為已知者溫習(xí)的目的而寫，錯(cuò)誤之處再所難

　　免，請(qǐng)大家提出寶貴意見和建議。本文講述以下內(nèi)容：

下面我們將針對(duì)上面的問(wèn)題分別進(jìn)行講述。

　　三、本章大綱

　　1、上章回顧。

　　2、摘要。

　　3、本章大綱。

　　4、服務(wù)層的介紹。

　　5、服務(wù)層實(shí)戰(zhàn)。

　　6、本章總結(jié)。

　　7、系列進(jìn)度。

　　8、下篇預(yù)告。

　　四、服務(wù)層的介紹

　　本節(jié)中將會(huì)對(duì)服務(wù)層的設(shè)計(jì)進(jìn)行詳細(xì)的分析。我們知道我們現(xiàn)在在軟件開發(fā)的過(guò)程中，通常我們會(huì)將一些業(yè)務(wù)邏輯的代碼寫在表現(xiàn)層，當(dāng)然這樣的方式不是不允

　　許，當(dāng)然一般情況下來(lái)說(shuō)我們感覺(jué)沒(méi)什么，但是采用這樣的方式，那么表現(xiàn)層與業(yè)務(wù)邏輯層之間的關(guān)系是耦合性的，可能我們是屬于那種希望設(shè)計(jì)簡(jiǎn)潔或者說(shuō)對(duì)設(shè)計(jì)規(guī)

　　范嚴(yán)格要求的時(shí)候，那么我們就可以考慮將業(yè)務(wù)邏輯的組織通過(guò)服務(wù)層來(lái)實(shí)現(xiàn)，那么服務(wù)層的作用就是將表現(xiàn)層與業(yè)務(wù)邏輯層之間完成解耦。那么表現(xiàn)層中就不會(huì)出現(xiàn)

　　任何的業(yè)務(wù)代碼，當(dāng)然這樣帶來(lái)的好處也是顯而易見的，就是當(dāng)我們修改業(yè)務(wù)層代碼時(shí)，我們不需要修改表現(xiàn)層的代碼，當(dāng)然如果服務(wù)層設(shè)計(jì)的不好，那么可能會(huì)造成

　　反效果。

　　服務(wù)層是干什么的？ 通過(guò)上面的簡(jiǎn)單介紹，我想大家都對(duì)服務(wù)層有了個(gè)簡(jiǎn)單的認(rèn)識(shí)，那么下面我們還是通過(guò)圖形的方式來(lái)看看服務(wù)層的位置及作用吧，可能那樣

　　更容易理解。

　　這幾層之間都是通過(guò)數(shù)據(jù)傳輸對(duì)象來(lái)完成各層之間的數(shù)據(jù)通信。通過(guò)上圖我們知道，服務(wù)層是通過(guò)數(shù)據(jù)傳輸對(duì)象

　　與業(yè)務(wù)邏輯層直接進(jìn)行交互，那么業(yè)務(wù)邏輯層與服務(wù)層具體交互的方式及內(nèi)容是什么呢？

　　下面我們來(lái)看看，業(yè)務(wù)邏輯層中的四種模式在服務(wù)層中的表現(xiàn)。

　　下面我們來(lái)舉例說(shuō)明服務(wù)層的作用。通過(guò)表現(xiàn)層與業(yè)務(wù)邏輯的解耦來(lái)說(shuō)明服務(wù)層的作用。我們還是以B2C中的購(gòu)物流程來(lái)說(shuō)。

　　我們先以購(gòu)物流程中的添加產(chǎn)品到購(gòu)物車來(lái)說(shuō)

　　可以簡(jiǎn)單的看作下面幾個(gè)對(duì)象之間的交互，首先我們先要選擇產(chǎn)品，然后將產(chǎn)品添加到購(gòu)物車

　　中，然后當(dāng)然這個(gè)購(gòu)物車是某個(gè)會(huì)員登陸以后的購(gòu)物清單，一個(gè)購(gòu)物車中可能有多個(gè)產(chǎn)品。我們來(lái)看看代碼可能如下：

　　我們定義的產(chǎn)品信息如下：

　　/// <summary> 
　　/// 產(chǎn)品信息  
　　/// </summary> 
　　public class Product  
　　{  
　　/// <summary> 
　　/// 返回所有的產(chǎn)品信息  
　　/// </summary> 
　　/// <returns></returns> 
　　public List<Product> GetAll()  
　　{  
　　return new List<Product>();  
　　}  
　　/// <summary> 
　　/// 返回產(chǎn)品信息根據(jù)產(chǎn)品ID  
　　/// </summary> 
　　/// <returns></returns> 
　　public Product GetByID(int ID)  
　　{  
　　return new Product();  
　　}  
　} 

　　產(chǎn)品信息中包含2個(gè)方法，一個(gè)是獲取所有產(chǎn)品的列表，還有一個(gè)是獲取實(shí)體的信息根據(jù)主鍵。我們來(lái)看看購(gòu)物車的代碼：

　　/// <summary>  
　　/// 購(gòu)物車  
　　/// </summary>  
　　public class ShopCar  
　　{  
　　/// <summary>  
　　/// 購(gòu)物車中的產(chǎn)品  
　/// </summary>  
　　Dictionary<int, Product> products = new Dictionary<int, Product>();  
　　/// <summary>  
　　/// 將指定產(chǎn)品ID的產(chǎn)品添加到購(gòu)物車  
　　/// </summary>  
　　public bool Add(int ID)  
　　{  
　　Product product = new Product();  
　　product= product.GetByID(ID);  
　　if (products.ContainsKey(ID))  
　　return false;  
　　products.Add(ID,product);  
　　return true;  
　}  
　　} 

　　下面我們來(lái)看看前臺(tái)調(diào)用的代碼：

　　public class ShopCar  
　　{  
　　/// <summary>  
　　/// 將指定產(chǎn)品ID的產(chǎn)品添加到購(gòu)物車  
　/// </summary>  
　　public bool Add(int ID)  
　　{  
　　ShopCar cart = new ShopCar();  
　　return cart.Add(ID);  
　　}  
　　} 

　　上面的代碼引用了ShopCar對(duì)象，說(shuō)明UI層的ShopCar與業(yè)務(wù)層的ShopCar 有依賴關(guān)系，那么我們?nèi)绾谓怦钅兀客ㄟ^(guò)引入第三方類，來(lái)實(shí)現(xiàn)依賴的解除。具體

　　的代碼如下：

　　public class ShopCar  
　　{  
　　/// <summary>  
　　/// 將指定產(chǎn)品ID的產(chǎn)品添加到購(gòu)物車  
　　/// </summary>  
　　public bool Add(int ID)  
　　{  
　　IShopCar car;  
　　CarFactory factory = new CarFactory();  
　　car = factory.ShopCarFactory();  
　　car.Add(ID);  
　　return true;  
　　}  
　　} 

　　修改后通過(guò)服務(wù)層中的購(gòu)物車工廠構(gòu)造出購(gòu)物車實(shí)例，這樣就可以把業(yè)務(wù)邏輯層與界面層之間的耦合關(guān)系通過(guò)新增加一個(gè)服務(wù)層來(lái)實(shí)現(xiàn)解耦，那么表現(xiàn)層的代碼更

　　簡(jiǎn)介，也符合設(shè)計(jì)規(guī)范。

　　其實(shí)我們這里的服務(wù)只是講述了服務(wù)層的簡(jiǎn)單應(yīng)用場(chǎng)景，其實(shí)具體的服務(wù)層在使用的過(guò)程中遠(yuǎn)比我們前面講解的復(fù)雜，首先可能服務(wù)層還會(huì)與數(shù)據(jù)訪問(wèn)層直接交

　　互，比如說(shuō)操作數(shù)據(jù)庫(kù)，持久化等，服務(wù)層主要是組織業(yè)務(wù)邏輯中的業(yè)務(wù)邏輯組件，服務(wù)層還通過(guò)ORM框架中提供的數(shù)據(jù)庫(kù)訪問(wèn)服務(wù)完成相應(yīng)的操作。我們前面講過(guò)，

　　一般情況下，表現(xiàn)層與服務(wù)層交互是，都是通過(guò)數(shù)據(jù)傳輸對(duì)象來(lái)進(jìn)行通信的，那么顯然有時(shí)候我們需要在服務(wù)層做處理，將數(shù)據(jù)傳輸對(duì)象轉(zhuǎn)換成領(lǐng)域模型，當(dāng)然有時(shí)候

　　我們?cè)谠O(shè)計(jì)系統(tǒng)架構(gòu)時(shí)，如果系統(tǒng)中的領(lǐng)域模型較多，或者說(shuō)是拆分后的數(shù)據(jù)傳輸對(duì)象太多時(shí)，我們只要將一個(gè)領(lǐng)域模型對(duì)應(yīng)一個(gè)數(shù)據(jù)傳輸對(duì)象就好，只不過(guò)是把領(lǐng)域

　　模型中的行為省略而已。

　　我們來(lái)看看目前比較流行的關(guān)于服務(wù)層的認(rèn)識(shí)：

　　我想目前最流行的關(guān)于服務(wù)層的架構(gòu)就是SOA（面向服務(wù)架構(gòu)），可以說(shuō)是SOA的出現(xiàn)才讓服務(wù)層流行起來(lái)，SOA中對(duì)服務(wù)的理解是這樣的，服務(wù)層是提供一系

　　列的服務(wù)，而具體的業(yè)務(wù)流程是通過(guò)一系列的服務(wù)組成的，把服務(wù)看作不是面向某種特定的技術(shù)，而是業(yè)務(wù)流程的組織方式。達(dá)到的目的是，提供了一系列的服務(wù)，只

　　需要配置組織服務(wù)的流程，就可以不管什么樣的技術(shù)，都能滿足要求的業(yè)務(wù)流程。當(dāng)然這是理想化的形式，具體的實(shí)行起來(lái)還是有相當(dāng)大的難度。

　　其實(shí)我們可以這樣想象，服務(wù)就是一個(gè)提供了API的類，通過(guò)封裝，外界訪問(wèn)服務(wù)時(shí)只能通過(guò)服務(wù)提供的接口來(lái)訪問(wèn)。

例如我們通過(guò)服務(wù)層提供上述的四種服務(wù)，然后在表現(xiàn)層中通過(guò)

　　服務(wù)層中的服務(wù)的調(diào)用來(lái)完成相應(yīng)的功能,比如我們?cè)诒憩F(xiàn)層中有新紀(jì)錄添加時(shí)，我們通過(guò)服務(wù)層的添加記錄的方法來(lái)完成，服務(wù)層通過(guò)提供的服務(wù)直接完成相應(yīng)的準(zhǔn)備

　　工作，并且這些服務(wù)在定義時(shí)都是通過(guò)接口的方式來(lái)向外提供功能，因此只要滿足接口契約就可以完成組件的替換工作，而不會(huì)影響系統(tǒng)的運(yùn)行。

　　我們有的時(shí)候有這樣的需求，我們的軟件程序要求既有B/S的形式直接通過(guò)瀏覽器來(lái)完成應(yīng)用，有時(shí)候還需要C/S客戶端的形式訪問(wèn)系統(tǒng)的功能，這時(shí)候我們?nèi)绻?/p>

　　通過(guò)服務(wù)來(lái)組織業(yè)務(wù)邏輯那么我們只需要寫一個(gè)服務(wù)層就可以完成遠(yuǎn)程服務(wù)訪問(wèn)，而不用B/S下寫一次業(yè)務(wù)邏輯調(diào)用，然后C/S下再寫一次，而且這樣一旦修改了相應(yīng)的

　　業(yè)務(wù)邏輯，那么我們需要變動(dòng)的代價(jià)很大。我們來(lái)看看服務(wù)層給我們提供了什么。

通過(guò)服務(wù)層我們可以不關(guān)心業(yè)務(wù)邏輯的實(shí)現(xiàn)，我們?cè)谟脩魣D形

　　化界面中只需要訪問(wèn)相關(guān)的服務(wù)即可，舉個(gè)簡(jiǎn)單例子，就行銀行的銀聯(lián)，跨行取款的行為。下面可以簡(jiǎn)單的描述了用戶取款的服務(wù)。

上面簡(jiǎn)單的描述了，用戶的取款服

　　務(wù)，當(dāng)然只要是銀聯(lián)的銀行卡，都可以享受到跨行的異地取款，當(dāng)然不管什么卡，提供給用戶的服務(wù)都是相同的。當(dāng)然我們這里說(shuō)的是C/S客戶端服務(wù)這樣的要求，當(dāng)

　　然如果說(shuō)是B/S架構(gòu)的形式，那么可能我們不用單獨(dú)抽出這樣的遠(yuǎn)程服務(wù)的形式。而服務(wù)層可能就是表現(xiàn)層的一部分，這時(shí)候我們建議不要把服務(wù)層設(shè)計(jì)成web服務(wù)，這

　　時(shí)候我們?cè)O(shè)計(jì)服務(wù)層時(shí)更關(guān)心服務(wù)層的抽象，而不是實(shí)現(xiàn)方式。

　　一般情況下來(lái)說(shuō)服務(wù)層的設(shè)計(jì)實(shí)現(xiàn)，可能有時(shí)候和部署時(shí)的要求有關(guān)，例如有時(shí)候我們需要將服務(wù)部署在應(yīng)用服務(wù)器上，這時(shí)候我們就必須考慮服務(wù)層必須發(fā)布成

　　遠(yuǎn)程調(diào)用服務(wù)或者Web服務(wù)，當(dāng)然具體的遠(yuǎn)程調(diào)用服務(wù)可以有幾種方式，我們主要看基于什么通信方式，是remoting還是soap，還是socket通信等。

　　當(dāng)然有時(shí)候我們對(duì)服務(wù)分為二種類型，粗粒度的服務(wù)與細(xì)粒度的服務(wù)，那么我們?cè)趺蠢斫馑兀科鋵?shí)說(shuō)白了粗粒度的服務(wù)就是某個(gè)大的服務(wù)，而細(xì)粒度的就是大

　　的服務(wù)內(nèi)部的子服務(wù)。可以這樣理解，粗粒度是按照用例來(lái)組織操作的，例如我們上面的銀行取款服務(wù)，那么粗粒度的服務(wù)就看作這樣的流程，用戶插卡-輸入密碼-取

　　款-退卡。而細(xì)粒度的服務(wù)關(guān)系的是：檢查用戶賬戶，余額的轉(zhuǎn)換等，包括一些比較詳細(xì)的，密碼的驗(yàn)證等等，這些都是細(xì)粒度的服務(wù)，可以把粗粒度看作某個(gè)用例的大

　　的業(yè)務(wù)操作，對(duì)領(lǐng)域中的對(duì)象不關(guān)心，只關(guān)心領(lǐng)域模型中的交互。細(xì)粒度可以看作領(lǐng)域模型中的具體對(duì)象及對(duì)象的行為。

　　接下來(lái)我們將講述服務(wù)層常用的幾種架構(gòu)模式：

第五節(jié)中將會(huì)詳細(xì)的講述每種模式及模式直接的區(qū)別及應(yīng)用。

　　我們來(lái)看看服務(wù)層的應(yīng)用場(chǎng)景及什么情況下使用服務(wù)層？

　　一般來(lái)說(shuō)服務(wù)層適合企業(yè)應(yīng)用系統(tǒng)中，也適合多層系統(tǒng)中，特別是業(yè)務(wù)邏輯比較復(fù)雜的系統(tǒng)程序中，如果說(shuō)應(yīng)用程序在多中形式的終端上使用時(shí)，推薦使用服務(wù)

　　層，當(dāng)然如果你的系統(tǒng)中只有一種類型的前端表現(xiàn)形式時(shí)，例如Web應(yīng)用程序，只有一個(gè)前端要求時(shí)，例如通過(guò)瀏覽器訪問(wèn)的形式，并且業(yè)務(wù)邏輯層能夠很好的與表現(xiàn)層交互時(shí)，那么如果我們還把業(yè)務(wù)邏輯與表現(xiàn)層直接的通信抽出來(lái)通過(guò)服

　　務(wù)層來(lái)完成的話，那么服務(wù)層只是完成任務(wù)的轉(zhuǎn)發(fā)，并沒(méi)有實(shí)際行的好處及減少開銷，那么此時(shí)不推薦使用服務(wù)層。

　　我們來(lái)總結(jié)下服務(wù)層的優(yōu)勢(shì)與劣勢(shì)，已衡量我們?cè)谙到y(tǒng)中使用服務(wù)層的必要性：

五、服務(wù)層實(shí)戰(zhàn)

　　前面已經(jīng)講述了服務(wù)層的優(yōu)缺點(diǎn)及應(yīng)用場(chǎng)景的介紹，那么我們本節(jié)中將要詳細(xì)的講解服務(wù)層設(shè)計(jì)的幾種模式，主要是體現(xiàn)出服務(wù)層設(shè)計(jì)實(shí)現(xiàn)的幾個(gè)思路，方便我

　　們?cè)陧?xiàng)目的實(shí)踐過(guò)程中少走彎路。為我們的系統(tǒng)帶來(lái)更好的適應(yīng)性及擴(kuò)展性要求。我們閑來(lái)將第一類模式

[[48636]]

　　裝飾模式在服務(wù)層的含義，跟設(shè)計(jì)模式中的裝飾模式可以說(shuō)是有著異曲同工之妙，就是將服務(wù)層的一系列方法包裝成干凈

　　的接口，以供外部調(diào)用，通過(guò)該模式，我們能夠?qū)⒓?xì)粒度的服務(wù)包裝成粗粒度的服務(wù)，這樣可以更方便的為表現(xiàn)層服務(wù)，并且可以通過(guò)裝飾模式將服務(wù)包裝成遠(yuǎn)程調(diào)用

　　服務(wù)的方式，具體內(nèi)部的實(shí)現(xiàn)都不是主要的關(guān)注點(diǎn)，對(duì)客戶來(lái)說(shuō)，他們可以以統(tǒng)一的方式不管客戶端的形式是怎么樣的。

　　我們都知道面向?qū)ο蟮脑O(shè)計(jì)原則是要求某個(gè)對(duì)象功能單一，盡可能的簡(jiǎn)單，但是通常我們?cè)诒憩F(xiàn)層中的一些業(yè)務(wù)流程中要求有多個(gè)實(shí)體之間進(jìn)行交互時(shí)，那么我

　　們通過(guò)服務(wù)來(lái)組織就會(huì)顯得比較好，我們通過(guò)裝飾模式來(lái)實(shí)現(xiàn)這樣的業(yè)務(wù)要求就會(huì)比較好，我們將一系列細(xì)粒度比較復(fù)雜的業(yè)務(wù)邏輯放在一個(gè)服務(wù)的API方法中，表現(xiàn)層

　　通過(guò)調(diào)用這個(gè)方法來(lái)完成復(fù)雜的業(yè)務(wù)邏輯交互。

　　服務(wù)層中的裝飾模式更關(guān)心的是如何為表現(xiàn)層提供更好的服務(wù)，隱藏內(nèi)部的細(xì)節(jié)，下面我們來(lái)看看相關(guān)的例子吧，我們這里還是以購(gòu)物流程來(lái)說(shuō)吧。

　　購(gòu)物流程的簡(jiǎn)單流程可能如此，那么當(dāng)然我們?cè)谫?gòu)物流程中還有其他的服務(wù)，比如我們?cè)谫?gòu)物的過(guò)程中的

　　短信提醒給賣家，或者說(shuō)是發(fā)送郵件給賣家。等這些是我們系統(tǒng)提供的服務(wù)，包括一些日志性的服務(wù)。那么這些我們?nèi)绾稳プ瞿兀慨?dāng)然在上面的流程中，用戶只需要關(guān)

　　系最后的一步，提交訂單，付款的環(huán)節(jié)，當(dāng)用戶付款后會(huì)給用戶發(fā)送短信，那么顯然我們?cè)诜?wù)中就可以把下單的過(guò)程中默認(rèn)提供系統(tǒng)日志，系統(tǒng)安全，權(quán)限等等問(wèn)題

　　一并處理，而給客戶提供的方法則只包含支付的接口。

　　public interface IPay  
　　{  
　　/// <summary> 
　　/// 支付接口  
　　/// </summary> 
　　/// <param name="product"></param> 
　　void Pay(Rule.Product product);  
　　} 

　　上面我們定義了支付的接口，來(lái)看業(yè)務(wù)層中的訂單操作：

　　public class Order  
　　{  
　　/// <summary> 
　　/// 添加產(chǎn)品  
　　/// </summary> 
　　/// <returns></returns> 
　　public int Add(Product product)  
　　{  
　　return 0;  
　　}  
　　/// <summary> 
　　/// 保存  
　　/// </summary> 
　　/// <returns></returns> 
　　public int Save()  
　　{  
　return 0;  
　　}  
　　/// <summary> 
　　/// 刪除  
　　/// </summary> 
　　/// <returns></returns> 
　　public int Delete()  
　　{  
　　return 0;  
　　}  
　　/// <summary> 
　　/// 更新  
　　/// </summary> 
　　/// <returns></returns> 
　　public int Update()  
　　{  
　　return 0;  
　　}  
　　} 

　　我們來(lái)看看服務(wù)類中接口的實(shí)現(xiàn)：

　　public class Pay : IPay  
　　{  
　　public bool PayMent(Rule.Product product)  
　　{  
　　//具體的下單操作  
　　Rule.Order order = new Rule.Order();  
　　//持久化操作  
　　order.Add(product);  
　　//發(fā)送手機(jī)短信，發(fā)送給賣家，通知有人買什么產(chǎn)品等  
　　SendMessage.Instance.SendMsg(string.Empty, string.Empty);  
　　return true;  
　　}  
　　#region IPay 成員  
　　public void IPay.Pay(Rule.Product product)  
　　{  
　　this.PayMent(product);  
　　}  
　#endregion  
　　} 

　　那么上面我們?cè)诜?wù)層組合多個(gè)簡(jiǎn)單的服務(wù)提供給一個(gè)方法，那么UI層只要簡(jiǎn)單的調(diào)用服務(wù)層接口中提供的方法即可，就能完成服務(wù)的調(diào)用。我們來(lái)看看UI層的代碼

　　public class Order  
　　{  
　　public void Pay()  
　{  
　　Service.PayFactory factory=new Service.PayFactory();  
　　//調(diào)用服務(wù)層中的支付  
　　Service.IPay pay = factory.CreatePay();  
　　//這里只是測(cè)試，所以沒(méi)有屏蔽New的代碼  
　　pay.Pay(new Rule.Product());  
　　}  
　　} 

　　那么通過(guò)上面的簡(jiǎn)單形式我們就完成了一個(gè)簡(jiǎn)單的裝飾模式的服務(wù)層的設(shè)計(jì)，是不是很簡(jiǎn)單呢？可能看起來(lái)代碼有點(diǎn)多，不過(guò)這樣的設(shè)計(jì)很利于我們?cè)诤笃诘臄U(kuò)展

　　性和適應(yīng)性，特別是等到系統(tǒng)的功能更復(fù)雜更多時(shí)。好的設(shè)計(jì)就能體現(xiàn)出它的價(jià)值了。

　　當(dāng)然上面我們通過(guò)了直接使用領(lǐng)域模型中的對(duì)象作為數(shù)據(jù)傳輸，當(dāng)然我們可以通過(guò)數(shù)據(jù)傳輸對(duì)象的自定義對(duì)象來(lái)完成，情況更好，我這里就不舉例說(shuō)明了，下面我

　　們來(lái)講述下一個(gè)模式：傳輸對(duì)象模式。

[[48638]]

　　那么我們前面也講過(guò)了數(shù)據(jù)傳輸對(duì)象，其實(shí)這個(gè)模式只是講解了數(shù)據(jù)傳輸對(duì)象的用法。

　　傳輸對(duì)象模式：

　　該模式主要是針對(duì)系統(tǒng)中各分層之間的數(shù)據(jù)傳輸模式的設(shè)計(jì)，通過(guò)傳輸對(duì)象可以降低各層之間分發(fā)數(shù)據(jù)的次數(shù)，提高系統(tǒng)性能，通常來(lái)說(shuō)該模式非常有用。但是也

　　有它的弊端。比如說(shuō)當(dāng)領(lǐng)域模型太多的時(shí)候，如果把領(lǐng)域模型中的每個(gè)對(duì)象的數(shù)據(jù)載體，都設(shè)計(jì)成傳輸對(duì)象，那么系統(tǒng)將是一個(gè)非常龐大的工程，因?yàn)檫^(guò)度設(shè)計(jì)，讓系

　　統(tǒng)難于維護(hù)與控制。我們來(lái)總結(jié)下使用該模式的優(yōu)缺點(diǎn)：

那么有優(yōu)點(diǎn)肯定就有缺點(diǎn)，我們來(lái)看看傳輸對(duì)象可能帶來(lái)的劣勢(shì)：

　　現(xiàn)在目前我們?cè)谑褂脭?shù)據(jù)傳輸對(duì)象的時(shí)候，都必須手動(dòng)的去維護(hù)及創(chuàng)建，目前沒(méi)有比較好的工具去完成自動(dòng)創(chuàng)建的功能。比如說(shuō)能將同一個(gè)對(duì)象，根據(jù)不同UI的需

　　求自動(dòng)的將一些屬性屏蔽或者啟用等。可能通過(guò)XML配置文件來(lái)完成會(huì)是可行的方案，不過(guò)目前還沒(méi)有一個(gè)比較好的工具去自動(dòng)的根據(jù)領(lǐng)域模型中的對(duì)象自動(dòng)的創(chuàng)建傳

　　輸對(duì)象，然后還能提供這個(gè)傳輸對(duì)象根據(jù)不同UI界面要求完成不同的自定義配置功能，希望各位如果了解的可以給小弟指點(diǎn)下，跪求！

　　傳輸對(duì)象模式我想具體的實(shí)例代碼我就簡(jiǎn)單的書寫下吧，就是把對(duì)象中的行為去掉，只包含數(shù)據(jù)信息，就和我們平時(shí)說(shuō)的3層結(jié)構(gòu)中的Model層一樣，只有g(shù)et;set;

　　訪問(wèn)器和私有成員變量，我們來(lái)看看實(shí)例代碼吧？

　　/// <summary>  
　　/// 產(chǎn)品信息  
　　/// </summary>  
　　public class Product  
　　{  
　　private int _pro_id;  
　　private string _pro_property = string.Empty;  
　　private string _pro_cid;  
　　private int? _pro_brandid;  
　　private string _pro_name;  
　　private string _pro_model;  
　　/// <summary>  
　　/// 產(chǎn)品ID  
　　/// </summary>  
　　public int pro_ID  
　　{  
　　set 
　　{  
　　_pro_id = value;  
　　}  
　　get 
　　{  
　　return _pro_id;  
　　}  
　　}  
　　/// <summary>  
　　/// 擴(kuò)展屬性值  
　　/// </summary>  
　　public string pro_Property  
　　{  
　　set 
　　{  
　　_pro_property = value;  
　　}  
　　get 
　{  
　　return _pro_property;  
　　}  
　　}  
　　/// <summary>  
　　/// 商品分類  
　　/// </summary>  
　　public string pro_CID  
　　{  
　　set 
　　{  
　　_pro_cid = value;  
　}  
　　get 
　　{  
　　return _pro_cid;  
　　}  
　　}  
　　/// <summary>  
　　/// 商品品牌  
　　/// </summary>  
　　public int? pro_BrandID  
　　{  
　　set 
　　{  
　　_pro_brandid = value;  
　　}  
　　get 
　　{  
　return _pro_brandid;  
　　}  
　　}  
　　/// <summary>  
　　/// 商品名稱  
　　/// </summary>  
　　public string pro_Name  
　　{  
　　set 
　　{  
_pro_name = value;  
　　}  
　　get 
　　{  
　return _pro_name;  
　　}  
　}  
　　/// <summary>  
　　/// 商品型號(hào)  
　　/// </summary>  
　　public string pro_Model  
　{  
　set 
　　{  
　　_pro_model = value;  
　　}  
　　get 
　　{  
　　return _pro_model;  
　　}  
　　}  
　　} 

　　我這里提供一個(gè)我認(rèn)為的生成領(lǐng)域模型的思路，主要還是通過(guò)XML文件來(lái)完成，將具體的數(shù)據(jù)傳輸對(duì)象不是通過(guò)類文件的形式來(lái)完成，通過(guò)序列化成XML文件來(lái)完

　　成，這樣就相當(dāng)于每個(gè)XML對(duì)應(yīng)一個(gè)序列化文件，然后這個(gè)文件中會(huì)保存相應(yīng)的配置信息，比如說(shuō)哪個(gè)頁(yè)面顯示哪些字段，那個(gè)頁(yè)面調(diào)用這個(gè)類時(shí)不掉用這個(gè)頁(yè)面。具

　　體的配置通過(guò)提供一個(gè)可視化的方式來(lái)維護(hù)就好了，然后在前臺(tái)綁定的時(shí)候根據(jù)讀取或者寫入XML文件來(lái)完成，可能這也是比較靈活的方式，具體的實(shí)現(xiàn)我沒(méi)有去做，

　　請(qǐng)大家提出更好的思路，小弟謝過(guò)！

　　我們接下來(lái)講述第三種模式：適配器模式，這個(gè)也是設(shè)計(jì)模式中最常用的設(shè)計(jì)模式的一種，適配器模式的主要作用是將某個(gè)接口轉(zhuǎn)換成我們需要的另外一個(gè)接口，

　　這個(gè)怎么理解呢？

　　我們把手機(jī)服務(wù)包裝成MP3的接口，或者把MP3的接口包裝成手機(jī)，都是可以的，可能我這里的例子舉得不合適

　　但是意思就是將某種服務(wù)，通過(guò)適配器轉(zhuǎn)換成另外一種服務(wù)。

　　我這里簡(jiǎn)單的講解幾個(gè)例子來(lái)完整適配器模式的介紹，我們先以將傳輸對(duì)象轉(zhuǎn)換為我們的領(lǐng)域模型中的對(duì)象，通過(guò)適配器來(lái)完成數(shù)據(jù)的轉(zhuǎn)換。

　　我們先來(lái)看看不通過(guò)適配器模式來(lái)完成領(lǐng)域?qū)ο笾械念惻c傳輸對(duì)象之間的交互，通過(guò)構(gòu)造函數(shù)注入的方式來(lái)完成。

　　/// <summary>  
　　/// 產(chǎn)品信息  
　　/// </summary>  
　　public class ProductCase  
　　{  
　　private Product _product;  
　public ProductCase(Product product)  
　　{  
　　_product = product;  
　　}  
　　/// <summary>  
　/// 產(chǎn)品ID  
　　/// </summary>  
　　public int pro_ID  
　　{  
　　set 
　　{  
　　_product.pro_ID = value;  
　　}  
　　get 
　　{  
　　return _product.pro_ID;  
　　}  
　　}  
　　/// <summary>  
　　/// 擴(kuò)展屬性值  
　　/// </summary>  
　public string pro_Property  
　　{  
　　set 
　　{  
　　_product.pro_Property = value;  
　　}  
　get 
　　{  
　return _product.pro_Property;  
　　}  
　　}  
　　/// <summary>  
　　/// 商品分類  
　　/// </summary>  
　　public string pro_CID  
　{  
　　set 
　　{  
　　_product.pro_CID = value;  
　　}  
　　get 
　　{  
　　return _product.pro_CID;  
　　}  
　　}  
　/// <summary>  
　　/// 商品品牌  
　　/// </summary>  
　　public int? pro_BrandID  
　　{  
　　set 
　　{  
　　_product.pro_BrandID = value;  
　　}  
　　get 
　　{  
　　return _product.pro_BrandID;  
　　}  
　　}  
　　/// <summary>  
　　/// 商品名稱  
　　/// </summary>  
　　public string pro_Name  
　　{  
　　set 
　　{  
　　_product.pro_Name = value;  
　　}  
　　get 
　　{  
　　return _product.pro_Name;  
　　}  
　　}  
　/// <summary>  
　　/// 商品型號(hào)  
　　/// </summary>  
　　public string pro_Model  
　　{  
　　set 
　　{  
_product.pro_Model = value;  
　}  
　　get 
　　{  
　　return _product.pro_Model;  
　　}  
　　}  
　} 

　　上面的方式通過(guò)構(gòu)造函數(shù)的注入完成相應(yīng)的訪問(wèn)，通過(guò)get;set;訪問(wèn)器來(lái)完成。

　　下面我們通過(guò)適配器的方式來(lái)實(shí)現(xiàn)轉(zhuǎn)換，看看有什么不同：

　　public class ProductTest  
　　{  
　　private Product _product;  
　　public ProductTest(Product product)  
　　{  
　ProductAdapter adapter = new ProductAdapter(product);  
　　adapter.InitDTO(this);  
　　}  
　} 

　　下面看看具體的適配器中的代碼：

　　public class ProductAdapter  
　　{  
　　private Product _product;  
　　public ProductAdapter(Product product)  
　　{  
　　this._product = product;  
　　}  
　　public bool InitDTO(ProductTest test)  
　　{  
　　//賦值的過(guò)程，將Product中的信息轉(zhuǎn)換為ProductTest對(duì)象  
　　test.pro_BrandID = _product.pro_BrandID;  
　　//...  
　　return true;  
　　}  
　　} 

　　我們上面看到了，通過(guò)依賴注入的形式，將要包裝的接口傳入到適配器，然后在適配器的內(nèi)部進(jìn)行相應(yīng)的包裝，傳出包裝后的接口，這就是一個(gè)完整的適配器流

　　程，具體的業(yè)務(wù)邏輯就是根據(jù)需要來(lái)做了。通過(guò)上面的方式我們的確完成了相應(yīng)的轉(zhuǎn)換，不過(guò)轉(zhuǎn)換的代價(jià)是非常的大，不過(guò)有的時(shí)候我們的業(yè)務(wù)需求是這樣的，可能我

　　們也沒(méi)有更好的辦法，只能通過(guò)這樣的方式來(lái)做，可能對(duì)解決方案的實(shí)現(xiàn)比效率更有價(jià)值。其實(shí)我們?cè)谑褂脗鬏攲?duì)象的時(shí)候還是需要仔細(xì)的斟酌項(xiàng)目的需求，看看是不

　　是必須要使用這個(gè)，如果不是必須的，其實(shí)我們可以不需要強(qiáng)迫性的使用。

　　六、本文總結(jié)

　　本章主要講述了系統(tǒng)架構(gòu)中的服務(wù)層的架構(gòu)中的注意事項(xiàng)及幾個(gè)簡(jiǎn)單的設(shè)計(jì)模式及使用，并且講述了服務(wù)層應(yīng)用的場(chǎng)景和帶來(lái)的好處，當(dāng)然我們也需要服務(wù)層的

　　優(yōu)劣處，還有就是服務(wù)的實(shí)現(xiàn)方案，本文前面可能沒(méi)有講解發(fā)布服務(wù)的幾種方式，這里簡(jiǎn)單的用圖來(lái)說(shuō)明下吧？

　　WCF已經(jīng)內(nèi)置繼承了remoting，socket和SOAP的方式來(lái)進(jìn)行遠(yuǎn)程調(diào)用服務(wù)，當(dāng)然HTTP方式的SOAP的服務(wù)方

　　式，還是推薦使用Web服務(wù)的方式來(lái)做。

　　模式需要注意的事項(xiàng),將會(huì)舉例說(shuō)明每個(gè)設(shè)計(jì)模式可能出現(xiàn)的場(chǎng)景。希望大家持續(xù)關(guān)注！

　　作者：CallHot-何戈洲

　　出處：http://www.cnblogs.com/hegezhou_hot/

【編輯推薦】

1. 系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之開卷有益
2. 系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之系統(tǒng)建模1
3. 系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之系統(tǒng)建模2
4. 系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之系統(tǒng)建模3
5. 系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之系統(tǒng)建模4
6. 系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之系統(tǒng)設(shè)計(jì)規(guī)范與原則1
7. 系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之系統(tǒng)設(shè)計(jì)規(guī)范與原則2
8. 系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之業(yè)務(wù)邏輯層
9. 系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之表現(xiàn)層
10. 系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之服務(wù)層