分層架構(gòu)模式 .NET架構(gòu)和模式

1、分層架構(gòu)模式:.NET架構(gòu)和模式瘋狂代碼 http:/CrazyC :http:/CrazyC什么是架構(gòu) 軟件Software體系結(jié)構(gòu)通常被稱為架構(gòu)指可以預(yù)制和可重構(gòu)軟件Software框架結(jié)構(gòu)架構(gòu)尚處在發(fā)展期對于其定義學(xué)術(shù)界尚未形成個統(tǒng)意見而區(qū)別角度視點也會造成軟件Software體系結(jié)構(gòu)區(qū)別理解以下是些主流標準觀點ANSI/IEEE 610.12-1990軟件Software工程標準詞匯對于體系結(jié)構(gòu)定義是:“體系架構(gòu)是以構(gòu)件、構(gòu)件的間關(guān)系、構(gòu)件和環(huán)境的間關(guān)系為內(nèi)容某系統(tǒng)基本組織結(jié)構(gòu)以及知道上述內(nèi)容設(shè)計和演化原理(principle”Mary Shaw和David Garlan認為軟件Sof

2、tware體系結(jié)構(gòu)是軟件Software設(shè)計過程中超越計算中算法設(shè)計和數(shù)據(jù)結(jié)構(gòu)設(shè)計個層次體系結(jié)構(gòu)問題包括各個方面組織和全局控制結(jié)構(gòu)通信協(xié)議、同步數(shù)據(jù)存儲給設(shè)計元素分配特定功能設(shè)計元素組織規(guī)模和性能在各設(shè)計方案的間進行選擇Garlan & Shaw模型基本思想是:軟件Software體系結(jié)構(gòu)=構(gòu)件(component,連接件(connector約束(constrain.其中構(gòu)件可以是組代碼如模塊;也可以是個獨立如數(shù)據(jù)庫服務(wù)器連接件可以是過程、管道、遠程過程(RPC等用于表示構(gòu)件的間相互作用約束般為對象連接時規(guī)則或指明構(gòu)件連接形式和條件例如上層構(gòu)件可要求下層構(gòu)件服務(wù)反的不行;兩對象不得遞規(guī)

3、地發(fā)送消息;代碼復(fù)制遷移致性約束;什么條件下此種連接無效等有關(guān)架構(gòu)定義還有很多其他觀點比如Bass定義、Booch & Rumbaugh &Jacobson定義、Perry & Wolf模型7、Boehm模型等等雖然各種定義關(guān)鍵架構(gòu)角度區(qū)別研究對象也略有側(cè)重但其核心內(nèi)容都是軟件Software系統(tǒng)結(jié)構(gòu)其中以Garlan & Shaw模型為代表強調(diào)了體系結(jié)構(gòu)基本要素是構(gòu)件、連接件及其約束(或者連接語義這些定義大部分是從構(gòu)造角度來甚至軟件Software體系結(jié)構(gòu)而IEEE定義不僅強調(diào)了系統(tǒng)基本組成同時強調(diào)了體系結(jié)構(gòu)環(huán)境即和外界交互什么是模式 模式(Pattern概念

4、最早由建筑大師Christopher Alexander于 2十世紀 7十年代提出應(yīng)用于建筑領(lǐng)域 8十年代中期由Ward Cunningham和Kent Beck將其思想引入到軟件Software領(lǐng)域Christopher Alexander將模式分為 3個部分:首先是周境(Context也可以稱著上下文,指模式在何種狀況下發(fā)生作用;其 2是動機( of Forces,意指問題或預(yù)期目標;其 3是解決方案(Solution,指平衡各動機或解決所闡述問題個構(gòu)造或配置(Configuration他提出模式是表示周境、動機、解決方案 3個方面關(guān)系個規(guī)則每個模式描述了個在某種周境下不斷重復(fù)發(fā)生問題以及

5、該問題解決方案核心所在模式即是個事物(thing又是個過程(process不僅描述該事物本身而且提出了通過怎樣過程來產(chǎn)生該事物這定義已被軟件Software界廣為接受軟件Software模式應(yīng)用對軟件Software開發(fā)產(chǎn)生了重大作用主要表現(xiàn)在:軟件Software模式是人們在長期設(shè)計軟件Software、管理組織軟件Software開發(fā)等實戰(zhàn)中大量經(jīng)驗提煉和抽象是復(fù)用軟件Software設(shè)計思路方法、過程管理經(jīng)驗有力工具模式類似于拳擊中組合拳它提供了系列軟件Software開發(fā)中思維套路如通過模式使用有利于在復(fù)雜系統(tǒng)中產(chǎn)生簡潔、精巧設(shè)計軟件Software模式為我們提供了套簡潔通用設(shè)計、管理

6、、組織方面詞匯同時模式也為我們提供了個描述抽象事物規(guī)范標準標準可大大促進軟件Software開發(fā)過程中人和人的間交流而軟件Software開發(fā)中交流是至關(guān)重要“軟件Software項目失敗原因最終都可追溯到信息沒有及時準確地傳遞到應(yīng)該接收它人”架構(gòu)和模式關(guān)系 架構(gòu)(Architecture和模式(Pattern在當前軟件Software開發(fā)中經(jīng)常地被提及可是很多人容易混淆這兩個術(shù)語而對此學(xué)術(shù)界也沒有個非常統(tǒng)定義架構(gòu)和模式應(yīng)該是個屬于相互涵蓋過程但是總體來說Architecture更加關(guān)注是所謂High-Level Design,而模式關(guān)注重點在于通過經(jīng)驗提取“準則或指導(dǎo)方案”在設(shè)計中應(yīng)用因此在

7、區(qū)別層面考慮問題時候就形成了區(qū)別問題域上Pattern模式目標是把共通問題中不變部分和變化部分分離出來不變部分就構(gòu)成了模式因此模式是個經(jīng)驗提取“準則”并且在次次實戰(zhàn)中得到驗證在區(qū)別層次有區(qū)別模式小到語言實現(xiàn)(如Singleton大到架構(gòu)在區(qū)別層面上模式提供區(qū)別層面指導(dǎo)根據(jù)處理問題粒度區(qū)別從高到低模式分為3個層次:架構(gòu)模式(Architectural Pattern、設(shè)計模式(Design Pattern、實現(xiàn)模式(Implementation Pattern.架構(gòu)模式是模式中最高層次描述軟件Software系統(tǒng)里基本結(jié)構(gòu)組織或綱要通常提供組事先定義好子系統(tǒng)指定它們責(zé)任并給出把它們組織在起法則和

8、指南比如用戶和文件系統(tǒng)安全策略模型N-層結(jié)構(gòu)組件對象服務(wù)等我們熟知MVC結(jié)構(gòu)也屬于架構(gòu)模式層次個架構(gòu)模式常常可以分解成很多個設(shè)計模式聯(lián)合使用設(shè)計模式是模式中第 2層次用來處理設(shè)計中反復(fù)出現(xiàn)問題例如GOF95整理總結(jié)23個基本設(shè)計模式Factory Pattern, Observer Pattern等等實現(xiàn)模式是最低也是最具體層次處理具體到編程語言問題比如類名變量名名命名規(guī)則;異常處理規(guī)則等等相對于系統(tǒng)分析或者設(shè)計模式來說體系結(jié)構(gòu)從更高層面去考慮問題所以關(guān)注問題就體現(xiàn)在“不變”原因上比如系統(tǒng)部署中更加關(guān)心應(yīng)用分層分級設(shè)計而在這個基礎(chǔ)的上提出部署方案才是架構(gòu)考慮重點體系結(jié)構(gòu)關(guān)心應(yīng)用模式更加體現(xiàn)在通

9、過技術(shù)去解決這些業(yè)務(wù)差異帶來影響關(guān)心是否是分布式應(yīng)用關(guān)心系統(tǒng)分層是如何設(shè)計也關(guān)心性能和安全因此在這樣情況的下會考慮集群負載平衡故障遷移等等系列技術(shù)希望通過定義方式來區(qū)分架構(gòu)和模式是不太可能本來就是交互交叉和提供服務(wù)它實際上是架構(gòu)模式而不是設(shè)計模式在大部份情況下表現(xiàn)為下面幾個設(shè)計模式的:Strategy模式、Mediator模式、Composite模式、Observer模式對于熟悉架構(gòu)設(shè)計系統(tǒng)架構(gòu)師而言似乎可以用如下來解釋架構(gòu)和模式的間關(guān)系:架構(gòu)是Hight-Level Design,著眼于區(qū)別業(yè)務(wù)中共性解決方案而模式是General Principle(通用原理企業(yè)解決方案構(gòu)建模式 企業(yè)級業(yè)務(wù)

10、解決方案是公司實現(xiàn)其業(yè)務(wù)賭注它們通常極其復(fù)雜而且性能必須不負眾望它們不僅必須具有高可用性和伸縮性以應(yīng)對不可預(yù)知使用而且還必須具有適應(yīng)性和預(yù)見性以適應(yīng)快速變化業(yè)務(wù)要求最佳解決方案是那些由組更小、簡單、能夠可靠且有效地解決簡單問題機制組成解決方案在構(gòu)建更大、更復(fù)雜系統(tǒng)過程中將這些簡單機制組合在起從而形成更大系統(tǒng)對這些簡單機制認識來的不易它通常存在于有經(jīng)驗開發(fā)人員和體系結(jié)構(gòu)設(shè)計者頭腦中并且是他們潛意識中自然帶到項目中重要知識模式對于開發(fā)人員和體系結(jié)構(gòu)設(shè)計者非常有用它們:記錄能夠正常工作簡單機制為開發(fā)人員和體系結(jié)構(gòu)設(shè)計者提供通用詞匯和分類法允許以模式組合方式簡明扼要地描述方案允許重復(fù)使用體系結(jié)構(gòu)、設(shè)計

11、和實現(xiàn)決策模式可以記錄簡單機制 模式描述給定上下文中反復(fù)出現(xiàn)問題并基于組指導(dǎo)性影響原因來建議解決方案解決方案通常是種簡單機制是為了解決模式中所標示出問題而起工作兩個或多個類、對象、服務(wù)、進程、線程、組件或節(jié)點的間協(xié)作您正在構(gòu)建個報價應(yīng)用其中有個類負責(zé)管理系統(tǒng)中所有報價很重要點是所有報價都應(yīng)和該類個(而且只和個例子進行交互如何構(gòu)造您設(shè)計以便從該應(yīng)用中只能訪問該類個例子?解決該問題最簡單方案就是創(chuàng)建個具有私用構(gòu)造QuoteManager類以便任何其他類都不能例子化它此類包含QuoteManager個靜態(tài)例子并使用名為GetInstance靜態(tài)思路方法返回此代碼大體如下所示:public Quote

12、Manager/注意:僅適用于單線程應(yīng)用private QuoteManager _Instance = null;private QuoteManager public QuoteManager GetInstance (_Instancenull_Instance = QuoteManager ; _Instance;/. QuoteManager提供您可能已經(jīng)像其他許多開發(fā)人員那樣通過類似方式解決過類似問題實際上注意反復(fù)出現(xiàn)問題并尋求解決方案模式作者已經(jīng)屢次發(fā)現(xiàn)了這種實現(xiàn)提取出了通用解決方案并將這種問題-解決方案對稱為Singleton模式GOF95問題-解決方案對模式 " a

13、lt=".NET架構(gòu)和模式" />圖1 簡化Singleton模式通過將圖1中簡化模式舉例和QuoteManager源代碼進行比較闡明了模式(通用問題-解決方案對和模式應(yīng)用(針對非常具體問題具體解決方案的間區(qū)別模式級別解決方案是多個類的間簡單但極其順暢協(xié)作模式中通用協(xié)作專門適用于QuoteManager類提供了用來控制報價應(yīng)用中例子化機制顯然您可以稍微修改下某種模式以滿足局部特定要求所以同種模式可以應(yīng)用于無數(shù)個應(yīng)用所編寫模式提供了種記錄簡單且經(jīng)過證實機制有效思路方法模式是以特定格式編寫這點對于裝載復(fù)雜思想容器非常有用這些模式在被記載和起名的前就早已存在于開發(fā)人員大腦及

14、其代碼中位于區(qū)別級別模式 模式存在于多個區(qū)別抽象級別中考慮另個舉例(這次所處抽象級別比源代碼要高級:您要設(shè)計個基于Web報價應(yīng)用其中包含大量業(yè)務(wù)和表示邏輯這些邏輯反過來依賴大量平臺軟件Software組件來提供適當執(zhí)行環(huán)境如何在高級別組織系統(tǒng)以使其在具有靈活、松耦合性同時仍具有高內(nèi)聚性?此問題解決方案的涉及到按系列層來組織系統(tǒng)每層包含大致位于同抽象級別元素隨后確定每層中依賴性并確定采用嚴格還是寬松分層策略接著決定是打算創(chuàng)建自定義分層方案還是采用以前由其他人記錄分層方案在本例中假設(shè)您決定使用眾所周知分層策略:表示、業(yè)務(wù)邏輯和數(shù)據(jù)訪問各占層圖2顯示了分層方案可能外觀" alt="

15、;.NET架構(gòu)和模式" />圖2 報價應(yīng)用層如果您總是按這種方式設(shè)計系統(tǒng)介紹說明您已經(jīng)在不依賴于任何廣義模式情況下使用該模式即便如此您還可能因多種原因而希望了解支撐這種設(shè)計思路方法模式您可能迫切想知道為何經(jīng)常以這種方式構(gòu)建系統(tǒng)或者可能在尋找更理想思路方法來解決此模式不能完全解決問題使用層作為高級別組織思路方法是Layers(層模式Buschmann96中描述完善模式圖3顯示了該模式簡化版本" alt=".NET架構(gòu)和模式" />圖3 簡化Layers模式這個簡單應(yīng)用組織策略有助于解決軟件Software開發(fā)中面臨兩個挑戰(zhàn):依存關(guān)系管理和對可交

16、換組件需求如果在構(gòu)建應(yīng)用時沒有個考慮周全依存關(guān)系管理策略會導(dǎo)致組件易損壞且不牢靠從而導(dǎo)致對它們進行維護、擴展和替代時存在較大困難而且成本較高Layers模式中工作機制比Singleton中工作機制更精細對于Layers首次協(xié)作是在設(shè)計時發(fā)生在類的間這是由于分層組織將對更改源代碼所帶來影響局部化從而防止所做更改貫穿到整個系統(tǒng)第 2次協(xié)作發(fā)生在運行時:某層中相對獨立組件變得可和其他組件交換再次使系統(tǒng)其余部分不受影響盡管Layers模式通用性足以應(yīng)用于諸如網(wǎng)絡(luò)協(xié)議、平臺軟件Software和虛擬機的類領(lǐng)域但是它無法解決企業(yè)類業(yè)務(wù)解決方案中存在某些特定問題例如除通過分解來管理復(fù)雜性(由Layers解決

17、基本問題外業(yè)務(wù)解決方案開發(fā)人員還需要進行適當組織以便有效地重復(fù)使用業(yè)務(wù)邏輯并保留和昂貴資源(如數(shù)據(jù)庫重要連接解決此問題思路方法的就是使用Three-Layered Application( 3層應(yīng)用模式圖4顯示了該模式簡化介紹說明" alt=".NET架構(gòu)和模式" />圖4 簡化Three-Layered Application同樣在模式(Three-Layered Application和模式應(yīng)用(報價應(yīng)用分層模型的間存在區(qū)別模式是有關(guān)應(yīng)用組織主題通用問題-解決方案對而模式應(yīng)用是通過創(chuàng)建具體層來解決非常具體問題模式優(yōu)化 Three-Layered Appl

18、ication實際上是在Layers基礎(chǔ)上進行簡單優(yōu)化;在Layers中確定上下文、影響原因和解決方案仍適用于Three-Layered Application但反的不行也就是說Layers模式約束著Three-Layered Application模式而Three-Layered Application模式優(yōu)化了Layers模式您為某個發(fā)展迅速成功企業(yè)構(gòu)建了個報價應(yīng)用現(xiàn)在您希望通過向業(yè)務(wù)合作伙伴公開自己報價引擎并將其他合作伙伴服務(wù)(如配送集成到該報價應(yīng)用中來擴展該應(yīng)用您將如何構(gòu)造自己業(yè)務(wù)應(yīng)用以提供和享受服務(wù)?此問題解決方案的是通過將其他和服務(wù)相關(guān)職責(zé)添加到每層中來擴展Three-Layered Application在業(yè)