在我們剛開(kāi)始學(xué)習(xí)架構(gòu)的時(shí)候，首先會(huì)想到分層的概念，分層架構(gòu)比較經(jīng)典的是三層架構(gòu)，那么，什么是三層架構(gòu)呢？它包括表現(xiàn)層，業(yè)務(wù)層，數(shù)據(jù)訪問(wèn)層；而對(duì)于一個(gè)新手來(lái)說(shuō)，從抽象意義上的三層架構(gòu)，邏輯上就劃分為三個(gè)層。

　　這個(gè)是最基本的三層架構(gòu)模式。

　　表現(xiàn)層充當(dāng)系統(tǒng)的界面呈現(xiàn)以及UI邏輯的角色，也就是說(shuō)，UI（用戶界面）屬于表現(xiàn)層；

　　舉一個(gè)對(duì)于ASP.NET WebForm來(lái)說(shuō)，人們喜歡把對(duì)于UI的控制邏輯（服務(wù)器控件的讀取、設(shè)置、事件等等）寫(xiě)在頁(yè)面的后置隱藏代碼中，并且依賴(lài)業(yè)務(wù)邏輯層。當(dāng)然，服務(wù)器控件支持?jǐn)?shù)據(jù)綁定的功能，可以通過(guò)數(shù)據(jù)源進(jìn)行綁定控件。這樣就可以節(jié)省在后置隱藏中的代碼。

　　因此，我們就可以把表現(xiàn)層分為UI用戶界面以及UI邏輯：

　　UI用戶界面的職責(zé)只是作為數(shù)據(jù)輸入和輸出后的展示工作。

　　UI邏輯的職責(zé)是負(fù)責(zé)業(yè)務(wù)邏輯層以及UI用戶界面之間的數(shù)據(jù)交互，并且盡可能地讓UI邏輯不依賴(lài)于UI技術(shù)。

　　其中UI用戶界面的實(shí)現(xiàn)方式有很多，包括ASP.NET，WinForm，WPF，Silverlight，移動(dòng)Web，智能設(shè)備等等。

　　將表現(xiàn)層中UI頁(yè)面和UI邏輯分離的策略中，當(dāng)前使用最多的兩種模式是MVC模式和MVP模式。

　　MVC模式，即模型-視圖-控制器模式，通過(guò)視圖觸發(fā)并執(zhí)行某個(gè)操作，調(diào)用控制器，通過(guò)控制器去操作業(yè)務(wù)層，最終返回模型，在視圖中進(jìn)行展示。這里的模型可以是一個(gè)領(lǐng)域模型（DM），也可以是一個(gè)數(shù)據(jù)傳輸對(duì)象（DTO）。

　　MVP模式，即模型-視圖-展示器模式，和MVC模式有點(diǎn)像，不同的是MVP中視圖和模型是被完全分離出來(lái)的，視圖中定義一個(gè)接口，而展示器通過(guò)調(diào)用該接口的方法以控制視圖。因此，視圖和模型是松散的，展示器也充當(dāng)了一個(gè)控制器的角色，同時(shí)它也不依賴(lài)于UI技術(shù)。

　　另外再介紹一種模式PM（Preentation Model），它可以說(shuō)是MVP的變體，在PM中，視圖不定義接口，這里的模型只是表示視圖狀態(tài)的類(lèi)，視圖中的元素被直接綁定到模型屬性上。例如在WPF中，WPF就先天的具有數(shù)據(jù)雙向綁定機(jī)制以及事件通知屬性機(jī)制。

　　所以它特別適用于WPF，Sliverlight等等。

　　在開(kāi)始業(yè)務(wù)層之前，不得不說(shuō)一個(gè)前提，在一個(gè)小型項(xiàng)目中，直接讓表現(xiàn)層調(diào)用業(yè)務(wù)層，足以解決所有問(wèn)題。但是，當(dāng)項(xiàng)目大到使用多種表現(xiàn)形式，如使用了各種UI技術(shù)，ASP.NET，WPF，移動(dòng)設(shè)備等等，就要考慮在你的表現(xiàn)層和業(yè)務(wù)層之間增加一個(gè)層，以至于讓表現(xiàn)層和業(yè)務(wù)層解耦，因?yàn)闃I(yè)務(wù)層作為一個(gè)業(yè)務(wù)中間件的平臺(tái)，最好不要暴露于表現(xiàn)層中，這個(gè)層就是傳說(shuō)中的服務(wù)層（推薦閱讀分層架構(gòu)中的服務(wù)層-服務(wù)層實(shí)戰(zhàn)）。架構(gòu)圖又演化為：

　　服務(wù)層實(shí)際上并不執(zhí)行任何具體的工作，其功能在于組織各個(gè)業(yè)務(wù)對(duì)象，服務(wù)層將業(yè)務(wù)層所有的細(xì)節(jié)對(duì)表現(xiàn)層都隱藏起來(lái)，服務(wù)器將組織業(yè)務(wù)邏輯層中的組件，并且通過(guò)數(shù)據(jù)傳輸對(duì)象(DTO)與表現(xiàn)層交互，因此就產(chǎn)生一個(gè)DTO模型。

　　為了實(shí)現(xiàn)服務(wù)的可重用性，需要使用服務(wù)接口，表現(xiàn)層通過(guò)規(guī)定的接口訪問(wèn)功能。服務(wù)的實(shí)現(xiàn)繼承服務(wù)接口，而服務(wù)的實(shí)現(xiàn)專(zhuān)注于業(yè)務(wù)層的調(diào)用。

　　對(duì)于服務(wù)層，常用的方法包括Web服務(wù)、.NET Remoting、REST以及WCF技術(shù)。

　　本人比較建議使用WCF作為服務(wù)，因?yàn)榭梢苑奖愕赝ㄟ^(guò)配置達(dá)到遠(yuǎn)程調(diào)用服務(wù)的目的。

　　服務(wù)層消除了兩個(gè)表現(xiàn)層和業(yè)務(wù)層之間的耦合，服務(wù)層可以實(shí)現(xiàn)一個(gè)遠(yuǎn)程接口，達(dá)到多UI技術(shù)甚至多平臺(tái)上的通信。

　　當(dāng)然增加服務(wù)層也有缺點(diǎn)，假如使用WCF服務(wù)，會(huì)增加系統(tǒng)的調(diào)用開(kāi)銷(xiāo)，進(jìn)而影響性能。

　　業(yè)務(wù)層中包含系統(tǒng)所需要業(yè)務(wù)過(guò)程上的實(shí)現(xiàn)，并與下層的數(shù)據(jù)訪問(wèn)層交互。

　　我們通常也叫做業(yè)務(wù)層叫做業(yè)務(wù)邏輯層，但我認(rèn)為業(yè)務(wù)邏輯層是屬于業(yè)務(wù)層的一方面，業(yè)務(wù)邏輯更專(zhuān)注于業(yè)務(wù)上邏輯算法的實(shí)現(xiàn)。因?yàn)闃I(yè)務(wù)層還可以包括其他的方面。

　　業(yè)務(wù)層必須包括對(duì)業(yè)務(wù)實(shí)體盡心建模的對(duì)象模型，表達(dá)了客戶的所有策略和需求的業(yè)務(wù)規(guī)則，因此就產(chǎn)生了領(lǐng)域模型。

　?。≒S：如果這里你不使用領(lǐng)域模型，那么需要采用業(yè)務(wù)規(guī)則層進(jìn)行業(yè)務(wù)功能上的業(yè)務(wù)規(guī)則的驗(yàn)證和控制）

　　領(lǐng)域模型包括對(duì)實(shí)體的屬性定義，方法定義以及實(shí)體與實(shí)體之間的關(guān)系。從這個(gè)角度上看，UML建模至關(guān)重要，通過(guò)對(duì)UML動(dòng)態(tài)圖和靜態(tài)圖的描述，可以映射到領(lǐng)域模型中。

　　從服務(wù)層剛才講到了DTO模型，這里需要一個(gè)機(jī)制將DTO轉(zhuǎn)化為領(lǐng)域模型，所以產(chǎn)生了DTO映射層（DTOMapper）。

　　另外，業(yè)務(wù)層還包括核心中間件技術(shù)，包括第三方組件，以及工作流引擎等等。

　　業(yè)務(wù)層需要考慮到一些與數(shù)據(jù)訪問(wèn)層交互的設(shè)計(jì)模式，模式中包括事物腳本模式、表模塊模式、活動(dòng)記錄模式、領(lǐng)域模型模式。

　　事物腳本模式是通過(guò)方法來(lái)執(zhí)行業(yè)務(wù)流程，它是一個(gè)過(guò)程式模型，事物腳本的每個(gè)方法都有一個(gè)特定的事物腳本，它側(cè)重于業(yè)務(wù)上一系列流程上的順序操作，它實(shí)現(xiàn)起來(lái)很簡(jiǎn)單，但是它有個(gè)致命的缺點(diǎn)就是它會(huì)造成很多重復(fù)的代碼。

　　表模塊模式比起事物腳本模式，具有一定的結(jié)構(gòu)，它的思想也很簡(jiǎn)單，每個(gè)數(shù)據(jù)表都定義一個(gè)業(yè)務(wù)組件（實(shí)體類(lèi)，實(shí)體操作類(lèi)），在.NET中更多的使用DataSet作為表模型的數(shù)據(jù)交互。但是它也有一個(gè)缺點(diǎn)就是它是從數(shù)據(jù)庫(kù)驅(qū)動(dòng)它不適合于大量的數(shù)據(jù)表以及數(shù)據(jù)表之間的復(fù)雜關(guān)系。

　　活動(dòng)記錄模式中的對(duì)象中，可以包含數(shù)據(jù)和方法。它接近于數(shù)據(jù)表的結(jié)構(gòu)，它的對(duì)象中執(zhí)行方法中可以包含CRUD操作，驗(yàn)證算法，以及其他的計(jì)算功能。一般來(lái)說(shuō)，領(lǐng)域模型不是太復(fù)雜，活動(dòng)記錄模式是個(gè)好選擇。當(dāng)然他也存在問(wèn)題，同樣地，它對(duì)于復(fù)雜的業(yè)務(wù)上，維護(hù)的成本也很高，并且如果需求變更導(dǎo)致數(shù)據(jù)庫(kù)修改，就需要調(diào)整記錄對(duì)象模型中的相關(guān)代碼。

　　經(jīng)典應(yīng)用：LINQ-TO-SQL以及Castle ActiveRecord。

　　領(lǐng)域模型模式是從領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中衍生來(lái)的，它是以業(yè)務(wù)為核心的設(shè)計(jì)模式。它對(duì)于復(fù)雜的業(yè)務(wù)邏輯，相當(dāng)適用。前三種方式使用的是以數(shù)據(jù)驅(qū)動(dòng)方式，數(shù)據(jù)驅(qū)動(dòng)方式特點(diǎn)簡(jiǎn)單，但是當(dāng)系統(tǒng)到了一定的規(guī)模后，就會(huì)到難以維護(hù)的程度。

　　數(shù)據(jù)訪問(wèn)層的目的很明確，主要作為提供數(shù)據(jù)持久化的功能，包括數(shù)據(jù)的讀取和寫(xiě)入，另外還必須包括事務(wù)處理，并發(fā)控制等等。

　　操作數(shù)據(jù)庫(kù)的方法可以有兩種方式：ORM方式，ADO.NET方式。

　　ORM可以采用一些第三方的ORM框架來(lái)實(shí)現(xiàn)，ADO.NET采用ASP.NET自帶的數(shù)據(jù)庫(kù)操作來(lái)實(shí)現(xiàn)。

　　不同的數(shù)據(jù)庫(kù)具有不同的持久化實(shí)現(xiàn)，因此這里添加一個(gè)存儲(chǔ)倉(cāng)庫(kù)接口層，來(lái)適應(yīng)不同的數(shù)據(jù)庫(kù)實(shí)現(xiàn)，這里你可以使用IOC依賴(lài)注入方式進(jìn)行數(shù)據(jù)庫(kù)選型，可以利用Unity、Spring.NET、Castle的IOC容器等等。

　　最后各個(gè)層中都可以依賴(lài)于公共基礎(chǔ)設(shè)施層。

　　公共基礎(chǔ)設(shè)施層可以包括Common通用模塊，Logging日志模塊，Exception異常模塊，Configuration配置模塊，DI依賴(lài)注入模塊，單元測(cè)試模塊以及第三方組件（例如NHibernate、Sprint.NET、Castle、Quartz計(jì)劃任務(wù)等等）

　　最終圖：

　　總結(jié)：項(xiàng)目類(lèi)型、項(xiàng)目規(guī)模以及業(yè)務(wù)上的需求，都影響著系統(tǒng)架構(gòu)的設(shè)計(jì)，系統(tǒng)架構(gòu)并不是一層不變的，沒(méi)有最好的架構(gòu)，只有更好的架構(gòu)，并且從項(xiàng)目中多思考系統(tǒng)的擴(kuò)展性。文中對(duì)于架構(gòu)的分析，只是從通常的角度上去考慮，在項(xiàng)目中，您還需要根據(jù)實(shí)際情況去做調(diào)整。

　　謝謝大家閱讀！

　　作者：李平 網(wǎng)名：Leepy 博客：http://www.cnblogs.com/liping13599168/

　　原文鏈接

it知識(shí)庫(kù)：談?wù)剬?duì)于企業(yè)級(jí)系統(tǒng)架構(gòu)的理解，轉(zhuǎn)載需保留來(lái)源！

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