[企業級架構]實在忍不住了，雖然儘可能想保持博文的原創性可是看見好的博文實在是忍不住了。。。

在咱們剛開始學習架構的時候，首先會想到分層的概念，分層架構比較經典的是三層架構，那麼，什麼是三層架構呢？它包括表現層，業務層，數據訪問層；而對於一個新手來講，從抽象意義上的三層架構，邏輯上就劃分爲三個層。

　　這個是最基本的三層架構模式。

　　表現層充當系統的界面呈現以及UI邏輯的角色，也就是說，UI（用戶界面）屬於表現層；

　　舉一個對於asp.net WebForm來講，人們喜歡把對於UI的控制邏輯（服務器控件的讀取、設置、事件等等）寫在頁面的後置隱藏代碼中，而且依賴業務邏輯層。固然，服務器控 件支持數據綁定的功能，能夠經過數據源進行綁定控件。這樣就能夠節省在後置隱藏中的代碼。

　　所以，咱們就能夠把表現層分爲UI用戶界面以及UI邏輯：

　　UI用戶界面的職責只是做爲數據輸入和輸出後的展現工做。

　　UI邏輯的職責是負責業務邏輯層以及UI用戶界面之間的數據交互，而且儘量地讓UI邏輯不依賴於UI技術。

　　其中UI用戶界面的實現方式有不少，包括ASP.NET，WinForm，WPF，Silverlight，移動Web，智能設備等等。

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

　　MVC模式，即模型-視圖-控制器模式，經過視圖觸發並執行某個操做，調用控制器，經過控制器去操做業務層，最終返回模型，在視圖中進行展現。這裏的模型能夠是一個領域模型（DM），也能夠是一個數據傳輸對象（DTO）。

　　MVP模式，即模型-視圖-展現器模式，和MVC模式有點像，不一樣的是MVP中視圖和模型是被徹底分離出來的，視圖中定義一個接口，而展現器經過調用該接口的方法以控制視圖。所以，視圖和模型是鬆散的，展現器也充當了一個控制器的角色，同時它也不依賴於UI技術。

　　另外再介紹一種模式PM（Preentation Model），它能夠說是MVP的變體，在PM中，視圖不定義接口，這裏的模型只是表示視圖狀態的類，視圖中的元素被直接綁定到模型屬性上。例如在WPF中，WPF就先天的具備數據雙向綁定機制以及事件通知屬性機制。

　　因此它特別適用於WPF，Sliverlight等等。

　 　在開始業務層以前，不得不說一個前提，在一個小型項目中，直接讓表現層調用業務層，足以解決全部問題。可是，當項目大到使用多種表現形式，如使用了各類 UI技術，ASP.NET，WPF，移動設備等等，就要考慮在你的表現層和業務層之間增長一個層，以致於讓表現層和業務層解耦，由於業務層做爲一個業務中 間件的平臺，最好不要暴露於表現層中，這個層就是傳說中的服務層（推薦閱讀分層架構中的服務層-服務層實戰）。架構圖又演化爲：

　　服務層實際上並不執行任何具體的工做，其功能在於組織各個業務對象，服務層將業務層全部的細節對錶現層都隱藏起來，服務器將組織業務邏輯層中的組件，而且經過數據傳輸對象(DTO)與表現層交互，所以就產生一個DTO模型。

　　爲了實現服務的可重用性，須要使用服務接口，表現層經過規定的接口訪問功能。服務的實現繼承服務接口，而服務的實現專一於業務層的調用。

　　對於服務層，經常使用的方法包括Web服務、.NET Remoting、REST以及WCF技術。

　　本人比較建議使用WCF做爲服務，由於能夠方便地經過配置達到遠程調用服務的目的。

　　服務層消除了兩個表現層和業務層之間的耦合，服務層能夠實現一個遠程接口，達到多UI技術甚至多平臺上的通訊。

　　固然增長服務層也有缺點，假如使用WCF服務，會增長系統的調用開銷，進而影響性能。

　　業務層中包含系統所須要業務過程上的實現，並與下層的數據訪問層交互。

　　咱們一般也叫作業務層叫作業務邏輯層，但我認爲業務邏輯層是屬於業務層的一方面，業務邏輯更專一於業務上邏輯算法的實現。由於業務層還能夠包括其餘的方面。

　　業務層必須包括對業務實體盡心建模的對象模型，表達了客戶的全部策略和需求的業務規則，所以就產生了領域模型。

　　（PS：若是這裏你不使用領域模型，那麼須要採用業務規則層進行業務功能上的業務規則的驗證和控制）

　　領域模型包括對實體的屬性定義，方法定義以及實體與實體之間的關係。從這個角度上看，UML建模相當重要，經過對UML動態圖和靜態圖的描述，能夠映射到領域模型中。

　　從服務層剛纔講到了DTO模型，這裏須要一個機制將DTO轉化爲領域模型，因此產生了DTO映射層（DTOMapper）。

　　另外，業務層還包括核心中間件技術，包括第三方組件，以及工做流引擎等等。

　　業務層須要考慮到一些與數據訪問層交互的設計模式，模式中包括事物腳本模式、表模塊模式、活動記錄模式、領域模型模式。

　　事物腳本模式是經過方法來執行業務流程，它是一個過程式模型，事物腳本的每一個方法都有一個特定的事物腳本，它側重於業務上一系列流程上的順序操做，它實現起來很簡單，可是它有個致命的缺點就是它會形成不少重複的代碼。

　　表模塊模式比起事物腳本模式，具備必定的結構，它的思想也很簡單，每一個數據表都定義一個業務組件（實體類，實體操做類），在.NET中更多的使用DataSet做爲表模型的數據交互。可是它也有一個缺點就是它是從數據庫驅動它不適合於大量的數據表以及數據表之間的複雜關係。

　　活動記錄模式中的對象中，能夠包含數據和方法。它接近於數據表的結構，它的對象中執行方法中能夠包含 CRUD操做，驗證算法，以及其餘的計算功能。通常來講，領域模型不是太複雜，活動記錄模式是個好選擇。固然他也存在問題，一樣地，它對於複雜的業務上， 維護的成本也很高，而且若是需求變動致使數據庫修改，就須要調整記錄對象模型中的相關代碼。

　　經典應用：LINQ-TO-SQL以及Castle ActiveRecord。

　　領域模型模式是從領域驅動設計中衍生來的，它是以業務爲核心的設計模式。它對於複雜的業務邏輯，至關適用。前三種方式使用的是以數據驅動方式，數據驅動方式特色簡單，可是當系統到了必定的規模後，就會到難以維護的程度。

　　數據訪問層的目的很明確，主要做爲提供數據持久化的功能，包括數據的讀取和寫入，另外還必須包括事務處理，併發控制等等。

　　操做數據庫的方法能夠有兩種方式：ORM方式，ADO.NET方式。

　　ORM能夠採用一些第三方的ORM框架來實現，ADO.NET採用ASP.NET自帶的數據庫操做來實現。

　　不一樣的數據庫具備不一樣的持久化實現，所以這裏添加一個存儲倉庫接口層，來適應不一樣的數據庫實現，這裏你可使用IOC依賴注入方式進行數據庫選型，能夠利用Unity、Spring.NET、Castle的IOC容器等等。

　　最後各個層中均可以依賴於公共基礎設施層。

　　公共基礎設施層能夠包括Common通用模塊，Logging日誌模塊，Exception異常模塊，Configuration配置模塊，DI依賴注入模塊，單元測試模塊以及第三方組件（例如NHibernate、Sprint.NET、Castle、Quartz計劃任務等等）

　　最終圖：

　　總結：項目類型、項目規模以及業務上的需求，都影響着系統架構的設計，系統架構並非一層不變的，沒有最好的架構，只有更好的架構，而且從項目中多思考系統的擴展性。文中對於架構的分析，只是從一般的角度上去考慮，在項目中，您還須要根據實際狀況去作調整。