關於多層架構一些思考

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》這篇文章 所思考，若有理解錯誤，望不吝賜教。

原文參考： http://www.codeproject.com/Articles/430014/N-Tier-Architecture-and-Tips