1：關于多層架構(N-Tier)
多層架構是一種被行業證明過的軟體架構模型，對開發一些解決可擴充性、安全性、容錯性方面的企業級(用戶端/服務端)應用程式支援是相當給力。但在.NET世界裡，我們有許多工具和産品，卻沒有指導手冊是關于如何設計和實作一個良好的多層架構模型，比如一些樣例版，Demo等等,我們或許多少有聽到、看到一些關于多層架構模型的用途和益處，但更多知道的僅僅是如何使用和實作，沒有過多的思考為何我們要這樣設計呢？這樣設計符合了哪些設計模式呢？遵循哪些設計原則呢？或者了解一點多層的概念，甚至是根本不了解其中的定義。是以本篇文章主旨是圍繞“多層架構”來打造，介紹其中的概念、優缺點、與其他架構差別、使用場景等等。但，總體來說，這是一個良好的軟體架構的解決方案之一。
2：名詞介紹
實體層和程序(Tier And Process)
在英文中都有表示層的意思，簡單來說——實體層和邏輯層。有一種說法是Layer是水準方向切割的，Tier是垂直方向切割的，這個隻是從觀察角度不同來定義的。Tier通常意味着實體部署的計算機，在一層可以單獨運作某一個服務。而Layer則意味着軟體功能相似的元件邏輯組合，Layer是為了能夠更好的開發，更好的組織。嚴格定義來說，
Tier是這樣的：客戶機->web伺服器->應用伺服器->資料庫，僅此而已。如果想要更多的Tiers，隻能去擴充應用伺服器，把應用伺服器分割出若幹的Tier。更多時候，一個Tier可以Host多個Layer外，某個Layer可以分布到多個Tier,比如提供基礎公共服務的Layer,對于富用戶端的應用程式，就是這種情況。
同時，Layer還暗示了"下面的Layer一般要為上面的Layer提供服務"，那麼用邏輯層來表達就顯得比較合适，而Tier這方面的暗示比較薄弱，用實體層來表達也貼切。
圖1：
在圖1中我們能看到，持久層(persistence layer)包含了兩部分：持久操作類庫(persistence lib)和wcf資料服務(wcf Data Service)。持久操作類型在持久層中通常運作同一個程序并結合wcf資料服務，作為業務層的提供者，而wcf資料服務，又可以單獨的運作在獨自的一實體層。另一個例子是，我們可能會從業務層中提取資料驗證來作為獨立的類庫(此時邏輯定義上，資料驗證還在業務層中)，是為了給客戶展現層調用提供更好的互動性能。那這樣的話，資料驗證類庫與客戶展現層運作的同一個程序中，而業務層剩餘的部分則單獨運作在一個實體層。
通常來說，一個邏輯層運作一個程序，并同時運作在一台單獨的計算機上。兩個不同邏輯層可以是在兩個不同的程序中獨立運作，程序間也互相通信。但如果碰到IPC情況，不是基于分布式的，那麼這兩個程序就會共享記憶體空間，那麼不同程序的處理得放在一個計算機中，那麼相對來說，一個實體層對應兩個程序，相當于對應兩個邏輯層
邏輯層和程序(Layer And Process)
通常，一個邏輯層運作在一個獨立的程序中，也有多個邏輯層運作在一個獨立的程序中，也有一個邏輯層運作多個程序。可以分不同種情況
3：三層架構
首先先介紹下三層架構，三層是多層架構中典型的例子。包括了：表示層、應用層、資料層，順序是從頂層到底層依次繼承。
表示層(Presentation layer)：使用者可以直接通路和互動的層次，比如桌面UI、網頁頁面等等，也可以叫為用戶端。
應用層(Application layer)：這個層封裝了業務邏輯(簡單來說就是業務運算的規則和資料驗證)，領域概念、資料通路邏輯等等，也可以叫為中間層
資料層(Data layer)：用來存取應用程式資料的外部資料源，比如資料庫服務，CRM系統，ERP系統，主機或者其他遺留系統等等。其中一個是我們常見的是資料庫服務，在多層架構中，我們需要使用到非嵌入式的資料服務系統，比如SQL Service,Oracle,DB2,MySql或者PostgraSQL.非嵌入式的資料庫服務可以運作在獨立計算機中，而嵌入式資料庫服務，比如access,db在獨立計算機，是以這種資料庫服務類型是不能在三層架構中使用的。
4：1-Tier,2-Tier,3-Tier或More-Tier架構
1-Tier：所有的邏輯層運作在一台計算機中，為了實作1-Tier架構，我們需要用到簽入式類型的資料庫系統，并且是不能運作在單獨的程序中，相反，那些至少2-Tier因為是非嵌入式資料庫通常可以在獨立的計算機中運作。
2-Tier：表示層和應用層，其中一個單獨運作在一台計算機中，或應用層和資料層，其中一個單獨運作在一台計算機中，整個應用程式不超過兩台計算機。
3-Tier：是多層架構中，最典型的一種。三層中的每一層都可以單獨運作在分離的計算機中，但也可以被部署在同一台計算機（其中最常見的是，三層架構，但最終部署作為一台中）。
N-Tier：3或者更多層架構。圖3描繪的是一個N層架構體系。一些三層類型可以進一步分割，變為多層架構。比如應用層可以進一步劃分為業務層和持久層，表示層可以進一步劃分為用戶端層和用戶端表現層。當然，所有這些邏輯層都可以部署在同一台計算機中的。
用戶端層：這個層是直接與使用者互動的，可能有幾種不同的類型共存，如WPF視窗，HTML網頁等等
用戶端表現層：包含客戶所需的表現邏輯。如asp.net mvc 的IIS伺服器，也适應不同客戶的業務層
業務層：處理并封裝業務所涉及的所有領域和邏輯，也可被稱為領域層
持久層：處理和對業務資料到資料層進行讀寫操作，也可被稱為資料通路層
資料層：外部的資料源，比如資料庫
5：N-Tier與MVC架構有什麼差別
MVC模式(Model-View-Controller)是軟體工程中的一種軟體架構模式，把軟體系統分為三個基本部分：模型(Model)、視圖(View)和控制器(Controller)。
1.控制器(Controller)- 負責轉發請求，對請求進行處理。
2.視圖(View) - 界面設計人員進行圖形界面設計。
3.模型(Model) - 程式員編寫程式應有的功能（實作算法等等）、資料庫專家進行資料管理和資料庫設計(可以實作具體的功能)。
就拿多層架構中最典型的三層來說，在三層中，資料通路層(DAL)、業務邏輯層(BLL)，Web層各司其職，目的是職責分離。MVC是Model-View-Controller。嚴格說起來這三個加起來才是三層架構中的Web層，換種說法就是MVC就是表示層中再度分化，分成了控制器、視圖、實體三個部分。View完成頁面邏輯，Model則封裝需要傳遞到View進行顯示的資料，而控制層則與三層中的BLL進行通信。
MVC的優點：耦合性低、重用性高、部署快、可維護性。
6：不同層架構優勢和劣勢
1 or 2-Tier 架構
優勢：由于流程和層次比較少，對于使用者數量少的應用程式是簡單又快速部署，同時又低成本的硬體、網絡維護。
劣勢：但當使用者數量增大時，将會出現大問題。由于隻能部署1到2台計算機，在程式的安全性、可擴充性、容錯性等方面會有局限性。
N-Tier架構
優勢：
1,可伸縮性。這是由于多層的功能和低耦合性所決定的。比如，由于沒有其他層的耦合，資料層可以擴大資料庫叢集，web用戶端可以通過負載平衡器擴大而不影響其他層，Windows伺服器可以輕松進行叢集通過負載平衡和故障轉移。
2,可安全性。更好和更安全的控制整個系統，我們可以對每個層執行不同的安全政策，比如，業務層和資料層通常比表示層需要更高的安全級别，我們可以把這兩高安全層放在防火牆後面進行保護。
3,可容錯性。比如，在不影響其他層的情況下，資料庫在資料層中可以為故障轉移，進行負載平衡叢集。
4,可獨立性。在不影響其他層情況下，可以進行獨立更新和改變。在面向對象世界裡，接口依賴實作可以把所有層解耦的非常好，那麼就會導緻如果其中某一層改變了，對于其他層是影響是非常小甚至是不影響。接口依賴意味着層跟層之間僅僅通過接口來互相通信，一層依賴于另一層的接口，而不是内部類來通信。當然，在改變整個系統時候，層的依賴性影響到的隻是他低層次的實作，進而把其中副作用的影響降到最低。比如，如果接口不改變，在不影響整個系統下，我們可以更改或替換這個接口所實作的層。
5,可便捷性。更便捷和更高效的開發環境，解耦主要是通過軟體元件組合來實作某一子產品，這樣軟體開發是非常便捷和高效的。可以把每一層要實作的功能單獨配置設定給不同的開發組，隻需通過接口來互相通信，每個層又可以自己做單元測試，到最後完成時組合起來就變成一個完整的系統。
6,可維護性。
7,可擴充性。由于對業務開發是以元件式來的，對于新功能的添加和删除是非常友善的。
8,可重用性。由于是高内聚和低耦合，通用的功能和代碼可以重複使用，也可以被其他更多的應用程式調用。
劣勢：
1，由于許多網絡、計算機和程序都是獨立運作的，一旦系統的硬體和網絡帶寬比較差的話，整個系統運作的性能就會比較慢。
2，如果需要更好的硬體和網絡帶寬，對于硬體和網絡、維護和部署的成本比較高。
7：多層架構中的業務資料驗證
在多層架構中，為了保證整個業務系統健康的和良好的，其中資料驗證是非常必須和重要的步驟。那麼首先有一個問題對于資料驗證？哪個層我們應該進行資料驗證，并且在哪裡進行驗證呢?這裡有幾個點：
1,可以任何一個層中進行資料驗證。通常，資料驗證離客戶層越近，是越高效。離用戶端越遠，則需要越可靠、越健壯。
2,當我們決定哪個層進行資料驗證時，我們需要處理好性能、可靠性和健壯之間的平衡關系。
3,用戶端驗證是是一種非常有效的手段，列如：Javascript用戶端驗證，當同時，使用者也可以輕松繞過用戶端驗證，比如網頁黑客所幹的事情。是以，在考慮性能和可靠性時候，在用戶端和服務的資料驗證是非常需要的。
4,對于一些資料互動的應用程式，無論我們是否将在伺服器端進行驗證，我們都需要在用戶端做可接受資料驗證。
8：多層架構中的開發技巧
設計、維護、實作、部署在多層架構中是一項艱巨的任務。如果一開始沒清晰的規劃，那麼有可能導緻後期開發的時候會做無用功。這裡有幾點如下建議：
1，用一些松散耦合的技術，盡可能把層和層之間的關系解耦，比如soap xml或接口等。在面向對象中，每一個層僅僅依賴于它接口所直接實作的具體層，而不是通過内聚類。這樣我們就可以盡可能的最大解耦，對于我們之後的開發會帶來更大的好處，比如單元測試、維護、系統更新，可擴充和可靠性。
2，盡可能多的自動生成技術或對于整個系統，通過poco版本方式進行業務實體的維護。利用特性、分部類、DTO等方法。
3，利用一些自動工具或包進行實體映射在業務實體和傳統的關系資料庫之間。比如Entity Framework 和 NHibernate 等工具。
4，利用代碼生成器。
5，我們應該盡量避免業務層與持久層的高度耦合，。比如，我們可以通過WCF業務服務來直接通路Entity Framework，這種情況很常見。但這樣做有一個問題是，會把業務層和持久層進行高度耦合。而這種高度耦合會帶來更多的問題。通常我們通過一種擴充卡來解決這種耦合，進而把高耦合變成松散耦合，他們僅僅通過接口來通信。
6，在客戶表現層，我們把共同的代碼抽象并封裝，以達到通用的目的。
7，為了提高性能，往往要增加緩存。
8，為了适應需求的變更，良好的多層架構可以輕松應對部署的伸縮性和配置的靈活性。
9：結論
描述了多層架構的概念和定義，介紹多層架構中的典型代表——"三層架構"。并說明了一個完整的三層架構應該是表示層、應用層、資料層分别運作在單獨的計算機中。并描述了三層架構和MVC架構之間的關系，應該是屬于和被屬于的關系。分析了多層架構的優勢和劣勢，在多層架構中的資料驗證的重要性，最後說明在多層架構中可以用到的一些工具和技術技巧，謹記層和層之間的通信是通過接口來互動，而不是内聚類，那樣才會做到開發時子產品的高内聚和通信的低耦合。
這是學習了《N-Tier Architecture and Tips》這篇文章 所思考，如有了解錯誤，望不吝賜教。
原文參考：http://www.codeproject.com/Articles/430014/N-Tier-Architecture-and-Tips