自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之服務(wù)層

作者：何戈洲
開發(fā) 架構(gòu)
系統(tǒng)架構(gòu)師是很多人羨慕的職業(yè)，不用天天埋頭寫代碼還能拿高薪。其實(shí)很多人并不了解企業(yè)應(yīng)用架構(gòu)，讓我們慢慢來學(xué)習(xí)。

　　一、上章回顧

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

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

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

　　二、摘要

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

　　過程中可能有些同仁，沒有用到該層，或者說是采用的是常用的分層結(jié)構(gòu)的設(shè)計(jì)，而沒有把服務(wù)層單獨(dú)的抽出來，當(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ì)上面的問題分別進(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ā)的過程中，通常我們會(huì)將一些業(yè)務(wù)邏輯的代碼寫在表現(xiàn)層，當(dāng)然這樣的方式不是不允

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

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

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

　　反效果。

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

　　更容易理解。

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

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

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

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

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

　　可以簡(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)品。我們來看看代碼可能如下：

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

  1. 　　/// <summary> 
  2. 　　/// 產(chǎn)品信息  
  3. 　　/// </summary> 
  4. 　　public class Product  
  5. 　　{  
  6. 　　/// <summary> 
  7. 　　/// 返回所有的產(chǎn)品信息  
  8. 　　/// </summary> 
  9. 　　/// <returns></returns> 
  10. 　　public List<Product> GetAll()  
  11. 　　{  
  12. 　　return new List<Product>();  
  13. 　　}  
  14. 　　/// <summary> 
  15. 　　/// 返回產(chǎn)品信息根據(jù)產(chǎn)品ID  
  16. 　　/// </summary> 
  17. 　　/// <returns></returns> 
  18. 　　public Product GetByID(int ID)  
  19. 　　{  
  20. 　　return new Product();  
  21. 　　}  
  22. 　} 

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

  1. 　　/// <summary>  
  2. 　　/// 購(gòu)物車  
  3. 　　/// </summary>  
  4. 　　public class ShopCar  
  5. 　　{  
  6. 　　/// <summary>  
  7. 　　/// 購(gòu)物車中的產(chǎn)品  
  8. 　/// </summary>  
  9. 　　Dictionary<int, Product> products = new Dictionary<int, Product>();  
  10. 　　/// <summary>  
  11. 　　/// 將指定產(chǎn)品ID的產(chǎn)品添加到購(gòu)物車  
  12. 　　/// </summary>  
  13. 　　public bool Add(int ID)  
  14. 　　{  
  15. 　　Product product = new Product();  
  16. 　　product= product.GetByID(ID);  
  17. 　　if (products.ContainsKey(ID))  
  18. 　　return false;  
  19. 　　products.Add(ID,product);  
  20. 　　return true;  
  21. 　}  
  22. 　　} 

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

  1. 　　public class ShopCar  
  2. 　　{  
  3. 　　/// <summary>  
  4. 　　/// 將指定產(chǎn)品ID的產(chǎn)品添加到購(gòu)物車  
  5. 　/// </summary>  
  6. 　　public bool Add(int ID)  
  7. 　　{  
  8. 　　ShopCar cart = new ShopCar();  
  9. 　　return cart.Add(ID);  
  10. 　　}  
  11. 　　} 

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

　　的代碼如下：

  1. 　　public class ShopCar  
  2. 　　{  
  3. 　　/// <summary>  
  4. 　　/// 將指定產(chǎn)品ID的產(chǎn)品添加到購(gòu)物車  
  5. 　　/// </summary>  
  6. 　　public bool Add(int ID)  
  7. 　　{  
  8. 　　IShopCar car;  
  9. 　　CarFactory factory = new CarFactory();  
  10. 　　car = factory.ShopCarFactory();  
  11. 　　car.Add(ID);  
  12. 　　return true;  
  13. 　　}  
  14. 　　} 

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

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

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

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

　　一般情況下，表現(xiàn)層與服務(wù)層交互是，都是通過數(shù)據(jù)傳輸對(duì)象來進(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)域模型較多，或者說是拆分后的數(shù)據(jù)傳輸對(duì)象太多時(shí)，我們只要將一個(gè)領(lǐng)域模型對(duì)應(yīng)一個(gè)數(shù)據(jù)傳輸對(duì)象就好，只不過是把領(lǐng)域

　　模型中的行為省略而已。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　然如果說是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)方式。

　　一般情況下來說服務(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í)說白了粗粒度的服務(wù)就是某個(gè)大的服務(wù)，而細(xì)粒度的就是大

　　的服務(wù)內(nèi)部的子服務(wù)?？梢赃@樣理解，粗粒度是按照用例來組織操作的，例如我們上面的銀行取款服務(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ì)象的行為。

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

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

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

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

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

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

　　我們來總結(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í)踐過程中少走彎路。為我們的系統(tǒng)帶來更好的適應(yīng)性及擴(kuò)展性要求。我們閑來將第一類模式

[[48636]]

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

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

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

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

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

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

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

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

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

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

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

  1. 　　public interface IPay  
  2. 　　{  
  3. 　　/// <summary> 
  4. 　　/// 支付接口  
  5. 　　/// </summary> 
  6. 　　/// <param name="product"></param> 
  7. 　　void Pay(Rule.Product product);  
  8. 　　} 

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

  1. 　　public class Order  
  2. 　　{  
  3. 　　/// <summary> 
  4. 　　/// 添加產(chǎn)品  
  5. 　　/// </summary> 
  6. 　　/// <returns></returns> 
  7. 　　public int Add(Product product)  
  8. 　　{  
  9. 　　return 0;  
  10. 　　}  
  11. 　　/// <summary> 
  12. 　　/// 保存  
  13. 　　/// </summary> 
  14. 　　/// <returns></returns> 
  15. 　　public int Save()  
  16. 　　{  
  17. 　return 0;  
  18. 　　}  
  19. 　　/// <summary> 
  20. 　　/// 刪除  
  21. 　　/// </summary> 
  22. 　　/// <returns></returns> 
  23. 　　public int Delete()  
  24. 　　{  
  25. 　　return 0;  
  26. 　　}  
  27. 　　/// <summary> 
  28. 　　/// 更新  
  29. 　　/// </summary> 
  30. 　　/// <returns></returns> 
  31. 　　public int Update()  
  32. 　　{  
  33. 　　return 0;  
  34. 　　}  
  35. 　　} 

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

  1. 　　public class Pay : IPay  
  2. 　　{  
  3. 　　public bool PayMent(Rule.Product product)  
  4. 　　{  
  5. 　　//具體的下單操作  
  6. 　　Rule.Order order = new Rule.Order();  
  7. 　　//持久化操作  
  8. 　　order.Add(product);  
  9. 　　//發(fā)送手機(jī)短信，發(fā)送給賣家，通知有人買什么產(chǎn)品等  
  10. 　　SendMessage.Instance.SendMsg(string.Empty, string.Empty);  
  11. 　　return true;  
  12. 　　}  
  13. 　　#region IPay 成員  
  14. 　　public void IPay.Pay(Rule.Product product)  
  15. 　　{  
  16. 　　this.PayMent(product);  
  17. 　　}  
  18. 　#endregion  
  19. 　　} 

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

  1. 　　public class Order  
  2. 　　{  
  3. 　　public void Pay()  
  4. 　{  
  5. 　　Service.PayFactory factory=new Service.PayFactory();  
  6. 　　//調(diào)用服務(wù)層中的支付  
  7. 　　Service.IPay pay = factory.CreatePay();  
  8. 　　//這里只是測(cè)試，所以沒有屏蔽New的代碼  
  9. 　　pay.Pay(new Rule.Product());  
  10. 　　}  
  11. 　　} 

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

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

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

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

[[48638]]

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

　　傳輸對(duì)象模式：

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

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

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

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

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

　　求自動(dòng)的將一些屬性屏蔽或者啟用等?？赡芡ㄟ^XML配置文件來完成會(huì)是可行的方案，不過目前還沒有一個(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í)說的3層結(jié)構(gòu)中的Model層一樣，只有g(shù)et;set;

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

  1. 　　/// <summary>  
  2. 　　/// 產(chǎn)品信息  
  3. 　　/// </summary>  
  4. 　　public class Product  
  5. 　　{  
  6. 　　private int _pro_id;  
  7. 　　private string _pro_property = string.Empty;  
  8. 　　private string _pro_cid;  
  9. 　　private int? _pro_brandid;  
  10. 　　private string _pro_name;  
  11. 　　private string _pro_model;  
  12. 　　/// <summary>  
  13. 　　/// 產(chǎn)品ID  
  14. 　　/// </summary>  
  15. 　　public int pro_ID  
  16. 　　{  
  17. 　　set 
  18. 　　{  
  19. 　　_pro_id = value;  
  20. 　　}  
  21. 　　get 
  22. 　　{  
  23. 　　return _pro_id;  
  24. 　　}  
  25. 　　}  
  26. 　　/// <summary>  
  27. 　　/// 擴(kuò)展屬性值  
  28. 　　/// </summary>  
  29. 　　public string pro_Property  
  30. 　　{  
  31. 　　set 
  32. 　　{  
  33. 　　_pro_property = value;  
  34. 　　}  
  35. 　　get 
  36. 　{  
  37. 　　return _pro_property;  
  38. 　　}  
  39. 　　}  
  40. 　　/// <summary>  
  41. 　　/// 商品分類  
  42. 　　/// </summary>  
  43. 　　public string pro_CID  
  44. 　　{  
  45. 　　set 
  46. 　　{  
  47. 　　_pro_cid = value;  
  48. 　}  
  49. 　　get 
  50. 　　{  
  51. 　　return _pro_cid;  
  52. 　　}  
  53. 　　}  
  54. 　　/// <summary>  
  55. 　　/// 商品品牌  
  56. 　　/// </summary>  
  57. 　　public int? pro_BrandID  
  58. 　　{  
  59. 　　set 
  60. 　　{  
  61. 　　_pro_brandid = value;  
  62. 　　}  
  63. 　　get 
  64. 　　{  
  65. 　return _pro_brandid;  
  66. 　　}  
  67. 　　}  
  68. 　　/// <summary>  
  69. 　　/// 商品名稱  
  70. 　　/// </summary>  
  71. 　　public string pro_Name  
  72. 　　{  
  73. 　　set 
  74. 　　{  
  75. _pro_name = value;  
  76. 　　}  
  77. 　　get 
  78. 　　{  
  79. 　return _pro_name;  
  80. 　　}  
  81. 　}  
  82. 　　/// <summary>  
  83. 　　/// 商品型號(hào)  
  84. 　　/// </summary>  
  85. 　　public string pro_Model  
  86. 　{  
  87. 　set 
  88. 　　{  
  89. 　　_pro_model = value;  
  90. 　　}  
  91. 　　get 
  92. 　　{  
  93. 　　return _pro_model;  
  94. 　　}  
  95. 　　}  
  96. 　　} 

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

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

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

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

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

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

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

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

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

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

  1. 　　/// <summary>  
  2. 　　/// 產(chǎn)品信息  
  3. 　　/// </summary>  
  4. 　　public class ProductCase  
  5. 　　{  
  6. 　　private Product _product;  
  7. 　public ProductCase(Product product)  
  8. 　　{  
  9. 　　_product = product;  
  10. 　　}  
  11. 　　/// <summary>  
  12. 　/// 產(chǎn)品ID  
  13. 　　/// </summary>  
  14. 　　public int pro_ID  
  15. 　　{  
  16. 　　set 
  17. 　　{  
  18. 　　_product.pro_ID = value;  
  19. 　　}  
  20. 　　get 
  21. 　　{  
  22. 　　return _product.pro_ID;  
  23. 　　}  
  24. 　　}  
  25. 　　/// <summary>  
  26. 　　/// 擴(kuò)展屬性值  
  27. 　　/// </summary>  
  28. 　public string pro_Property  
  29. 　　{  
  30. 　　set 
  31. 　　{  
  32. 　　_product.pro_Property = value;  
  33. 　　}  
  34. 　get 
  35. 　　{  
  36. 　return _product.pro_Property;  
  37. 　　}  
  38. 　　}  
  39. 　　/// <summary>  
  40. 　　/// 商品分類  
  41. 　　/// </summary>  
  42. 　　public string pro_CID  
  43. 　{  
  44. 　　set 
  45. 　　{  
  46. 　　_product.pro_CID = value;  
  47. 　　}  
  48. 　　get 
  49. 　　{  
  50. 　　return _product.pro_CID;  
  51. 　　}  
  52. 　　}  
  53. 　/// <summary>  
  54. 　　/// 商品品牌  
  55. 　　/// </summary>  
  56. 　　public int? pro_BrandID  
  57. 　　{  
  58. 　　set 
  59. 　　{  
  60. 　　_product.pro_BrandID = value;  
  61. 　　}  
  62. 　　get 
  63. 　　{  
  64. 　　return _product.pro_BrandID;  
  65. 　　}  
  66. 　　}  
  67. 　　/// <summary>  
  68. 　　/// 商品名稱  
  69. 　　/// </summary>  
  70. 　　public string pro_Name  
  71. 　　{  
  72. 　　set 
  73. 　　{  
  74. 　　_product.pro_Name = value;  
  75. 　　}  
  76. 　　get 
  77. 　　{  
  78. 　　return _product.pro_Name;  
  79. 　　}  
  80. 　　}  
  81. 　/// <summary>  
  82. 　　/// 商品型號(hào)  
  83. 　　/// </summary>  
  84. 　　public string pro_Model  
  85. 　　{  
  86. 　　set 
  87. 　　{  
  88. _product.pro_Model = value;  
  89. 　}  
  90. 　　get 
  91. 　　{  
  92. 　　return _product.pro_Model;  
  93. 　　}  
  94. 　　}  
  95. 　} 

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

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

  1. 　　public class ProductTest  
  2. 　　{  
  3. 　　private Product _product;  
  4. 　　public ProductTest(Product product)  
  5. 　　{  
  6. 　ProductAdapter adapter = new ProductAdapter(product);  
  7. 　　adapter.InitDTO(this);  
  8. 　　}  
  9. 　} 

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

  1. 　　public class ProductAdapter  
  2. 　　{  
  3. 　　private Product _product;  
  4. 　　public ProductAdapter(Product product)  
  5. 　　{  
  6. 　　this._product = product;  
  7. 　　}  
  8. 　　public bool InitDTO(ProductTest test)  
  9. 　　{  
  10. 　　//賦值的過程，將Product中的信息轉(zhuǎn)換為ProductTest對(duì)象  
  11. 　　test.pro_BrandID = _product.pro_BrandID;  
  12. 　　//...  
  13. 　　return true;  
  14. 　　}  
  15. 　　} 

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

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

　　們也沒有更好的辦法，只能通過這樣的方式來做，可能對(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)景和帶來的好處，當(dāng)然我們也需要服務(wù)層的

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

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

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

　　模式需要注意的事項(xiàng),將會(huì)舉例說明每個(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ù)層
責(zé)任編輯：彭凡 來源： 博客園
系統(tǒng)架構(gòu)師
相關(guān)推薦

2011-10-31 09:22:07

系統(tǒng)架構(gòu)

2011-10-27 09:08:59

系統(tǒng)架構(gòu)師

2011-11-02 09:01:30

系統(tǒng)架構(gòu)師

2011-10-18 09:25:04

系統(tǒng)架構(gòu)師

2011-10-20 09:06:36

系統(tǒng)架構(gòu)師

2011-10-24 09:26:42

系統(tǒng)架構(gòu)師

2011-10-19 09:20:44

2011-10-21 09:04:57

系統(tǒng)架構(gòu)師

2011-10-25 08:59:28

系統(tǒng)架構(gòu)師

2011-10-26 09:43:13

系統(tǒng)架構(gòu)師

2012-02-02 10:23:07

2010-08-05 13:51:13

軟件架構(gòu)師

2011-03-11 15:38:08

Java

2015-06-23 14:43:16

騰訊云架構(gòu)師可擴(kuò)展系統(tǒng)

2014-10-28 09:56:56

Hadoop

2010-08-09 09:03:17

.NET企業(yè)級(jí)架構(gòu)

2010-08-30 11:06:21

企業(yè)架構(gòu)師

2009-06-30 16:34:44

微軟

2011-03-25 10:23:51

架構(gòu)師

2012-06-20 13:54:44

架構(gòu)性能優(yōu)化
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)