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資料服務，又可以單獨的執行在獨自的一物理層。另一個例子是，我們可能會從業務層中提取資料驗證來作為獨立的類庫(此時邏輯定義上，資料驗證還在業務層中)，是為了給客戶展現層呼叫提供更好的互動效能。那這樣的話，資料驗證類庫與客戶展現層執行的同一個程式中，而業務層剩餘的部分則單獨執行在一個物理層。
物理層和程式(Tier And Process)
通常來說，一個邏輯層執行一個程式，並同時執行在一臺單獨的計算機上。兩個不同邏輯層可以是在兩個不同的程式中獨立執行，程式間也互相通訊。但如果碰到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》這篇文章 所思考，如有理解錯誤，望不吝賜教。