[[335794]]

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

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

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

舉一個對于asp.net WebForm來說，人們喜歡把對于UI的控制邏輯(服務(wù)器控件的讀取、設(shè)置、事件等等)寫在頁面的后置隱藏代碼中，并且依賴業(yè)務(wù)邏輯層。當然，服務(wù)器控件支持數(shù)據(jù)綁定的功能，可以通過數(shù)據(jù)源進行綁定控件。這樣就可以節(jié)省在后置隱藏中的代碼。

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

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

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

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

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

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

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

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

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

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

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

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

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

本人比較建議使用WCF作為服務(wù)，因為可以方便地通過配置達到遠程調(diào)用服務(wù)的目的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最終圖：

總結(jié)：項目類型、項目規(guī)模以及業(yè)務(wù)上的需求，都影響著系統(tǒng)架構(gòu)的設(shè)計，系統(tǒng)架構(gòu)并不是一層不變的，沒有最好的架構(gòu)，只有更好的架構(gòu)，并且從項目中多思考系統(tǒng)的擴展性。

作者：Leepy