三層架構（一）

三層架構：

一般意義上的三層架構就是將整個業務應用劃分爲：界面層（User Interface layer）、業務邏輯層（Business Logic Layer）、數據訪問層（Data access layer）。區分層次的目的即爲了「高內聚低耦合」的思想。在軟件體系架構設計中，分層式結構是最多見，也是最重要的一種結構。微軟推薦的分層式結構通常分爲三層，從下至上分別爲：數據訪問層、業務邏輯層（又或稱爲領域層）、表示層。

 

顧名思義，三層架構分爲三層，分別是「數據訪問層」、「業務邏輯層」、「表示層」。

數據訪問層：數據訪問層在做業過程當中訪問數據系統中的文件，實現對數據庫中數據的讀取保存操做。

表示層：主要功能是顯示數據和接受傳輸用戶的數據，能夠在爲網站的系統運行提供交互式操做界面，表示層的應用方式比較常見，例如Windows窗體和Web頁面。

業務邏輯層：將用戶的輸入信息進行甄別處理，分別保存。創建新的數據存儲方式，在存儲過程當中對數據進行讀取，將「商業邏輯」描述代碼進行包含。

三層架構軟件系統爲用戶的數據傳輸、提取、儲存創造了便利條件。在應用數據時，信息劃分架構開發項目，對各層次之間的工做職責進行清晰規劃，這樣就下降了網站系統的維護風險。

原理：

3個層次中，系統主要功能和業務邏輯都在業務邏輯層進行處理。

所謂三層體系結構，是在客戶端與數據庫之間加入了一個「中間層」，也叫組件層。這裏所說的三層體系，

不是指物理上的三層，也不是簡單地放置三臺機器就是三層體系結構，固然也不只僅有B/S應用纔是三層體系結構，

三層是指邏輯上的三層，即把這三個層放置到一臺機器上。

三層體系的應用程序將業務規則、數據訪問、合法性校驗等工做放到了中間層進行處理。一般狀況下，客戶端不直接與數據庫進行交互，而是經過COM/DCOM通信與中間層創建鏈接，再經由中間層與數據庫進行交互。

三層架構中主要功能與業務邏輯通常要在業務邏輯層進行信息處理和實現，其中三層體系架構中的客戶端和數據庫要預設中間層，成爲組建層。三層架構中的三層具備必定的邏輯性，便是將三層設置到同一個計算機系統中，把業務協議、合法校驗以及數據訪問等程序歸置到中間層進行信息處理，通常客戶端沒法和數據庫進行數據傳輸，主要是利用COM/DCOM通信和中間層構建銜接通道，實現中間層與數據庫的數據傳輸，進而實現客戶端與是數據庫的交互。

 

結構：

 

表示層

表示層又稱表現層UI，位於三層構架的最上層，與用戶直接接觸，主要是B/S信息系統中的Web瀏覽頁面。做爲Web瀏覽頁面，表示層的主要功能是實現系統數據的傳入與輸出，在此過程當中不須要藉助邏輯判斷操做就能夠將數據傳送到BLL系統中進行數據處理，處理後會將處理結果反饋到表示層中。換句話說，表示層就是實現用戶界面功能，將用戶的需求傳達和反饋，並用BLL或者是Models進行調試，保證用戶體驗。

 

業務邏輯層

業務邏輯層BLL的功能是對具體問題進行邏輯判斷與執行操做，接收到表現層UI的用戶指令後，會鏈接數據訪問層DAL，訪問層在三層構架中位於表示層與數據層中間位置，同時也是表示層與數據層的橋樑，實現三層之間的數據鏈接和指令傳達，能夠對接收數據進行邏輯處理，實現數據的修改、獲取、刪除等功能，並將處理結果反饋到表示層UI中，實現軟件功能。

 

數據訪問層

數據訪問層DAL是數據庫的主要操控系統，實現數據的增長、刪除、修改、查詢等操做，並將操做結果反饋到業務邏輯層BLL。在實際運行的過程當中，數據訪問層沒有邏輯判斷能力，爲了實現代碼編寫的嚴謹性，提升代碼閱讀程度，通常軟件開發人員會在該層中編寫DataAccessCommon，保證數據訪問層DAL數據處理功能。

簡單的說法就是實現對數據表的Select（查詢），Insert（插入），Update（更新），Delete（刪除）等操做。若是要加入ORM的元素，那麼就會包括對象和數據表之間的mapping，以及對象實體的持久化。

數據訪問層，簡單的說，就是經過DAL對數據庫進行的SQL語句等操做。

數據庫訪問層的主要職責是：讀取數據和傳遞數據。

 

 

各層的做用

一、數據訪問層：主要是對非原始數據（數據庫或者文本文件等存放數據的形式）的操做層，而不是指原始數據，也就是說，是對數據庫的操做，而不是數據，具體爲業務邏輯層或表示層提供數據服務。

二、業務邏輯層：主要是針對具體的問題的操做，也能夠理解成對數據層的操做，對數據業務邏輯處理，若是說數據層是積木，那邏輯層就是對這些積木的搭建。

三、界面層：主要表示WEB方式，也能夠表示成WINFORM方式，WEB方式也能夠表現成：aspx，若是邏輯層至關強大和完善，不管表現層如何定義和更改，邏輯層都能完善地提供服務

舉個例子

服務員：只管接待客人；

廚師：只管作客人點的菜；

採購員：只管按客人點菜的要求採購食材；

他們各負其職，服務員不用瞭解廚師如何作菜，不用瞭解採購員如何採購食材；

廚師不用知道服務員接待了哪位客人，不用知道採購員如何採購食材；

一樣，採購員不用知道服務員接待了哪位客人，不用知道廚師如何作菜。

那他們三者是如何聯繫的？

顧客直接和服務員打交道，顧客和服務員（UI層）說：我要一個炒茄子，而服務員不負責炒茄子，她就把請求往上遞交，傳遞給廚師（BLL層），廚師須要茄子，就把請求往上遞交，傳遞給採購員（DAL層），採購員從倉庫裏取來茄子傳回給廚師，廚師響應cookEggplant()方法，作好炒茄子後，又傳回給服務員，服務員把茄子呈現給顧客。

這樣就完成了一個完整的操做。

在此過程當中，茄子做爲參數在三層中傳遞，若是顧客點炒雞蛋，則雞蛋做爲參數（這是變量作參數）。若是，用戶增長需求，咱們還得在方法中添加參數，一個方法添加一個，一個方法設計到三層；況且實際中並不止設計到一個方法的更改。因此，爲了解決這個問題，咱們能夠把茄子、雞蛋、麪條做爲屬性定義到顧客實體中，一旦顧客增長了炒雞蛋需求，直接把雞蛋屬性拿出來用便可，不用再去考慮去每層的方法中添加參數了，更不用考慮參數的匹配問題。

這樣講，你們應該能夠明白吧

這只是一部分的內容，另外一部分請看個人另外一篇博客

（三層構架二）