轉自：http://www.cnblogs.com/liping13599168/archive/2011/05/11/2043127.html
在我們剛開始學習架構的時候，首先會想到分層的概念，分層架構比較經典的是三層架構，那麼，什麼是三層架構呢？它包括表現層，業務層，資料通路層；而對于一個新手來說，從抽象意義上的三層架構，邏輯上就劃分為三個層。
這個是最基本的三層架構模式。
表現層充當系統的界面呈現以及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計劃任務等等）
最終圖：
總結：項目類型、項目規模以及業務上的需求，都影響着系統架構的設計，系統架構并不是一層不變的，沒有最好的架構，隻有更好的架構，并且從項目中多思考系統的擴充性。文中對于架構的分析，隻是從通常的角度上去考慮，在項目中，您還需要根據實際情況去做調整。
謝謝大家閱讀！