三層架構（轉載）

A.三層架構：

   數據訪問層(DAL):該層所作事務直接操做數據庫，針對數據的增添、刪除、修改、查找等。因此D層的類對應的就是表。

   業務邏輯層(BLL):針對具體問題的操做，也能夠說是對數據層的操做，對數據業務邏輯處理。

   表示層(UI):通俗講就是展示給用戶的界面，即用戶在使用一個系統的時候他的所見所得。

   實體層（Entity）:就是數據庫全部表的。每一個表都是一個類，表的字段就是屬性。實體層爲傳遞各類數據的容器，至關於一個載體。(下面不做過多介紹)

 

B.三層結構原理：

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

   所謂三層體系結構，是在客戶端與數據庫之間加入了一個「中間層」，也叫組件層。三層體系的應用程序將業務規則、數據訪問、合法性校驗等工做放到了中間層進行處理（以下圖）。一般狀況下，客戶端不直接與數據庫進行交互，而是經過COM/DCOM通信與中間層創建鏈接，再經由中間層與數據庫進行交互。

 

 

 

C.三層之間的關係：以下圖

  

D.三層中各層的做用：

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

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

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

E.各層的具體區分方法:

 1：數據訪問層：主要看你的數據層裏面有沒有包含邏輯處理，實際上他的各個函數主要完成各個對數據文件的操做。而沒必要管其餘操做。數據訪問層有時候也稱爲是持久層，其功能主要是負責數據庫的訪問，能夠訪問數據庫系統、二進制文件、文本文檔或是XML文檔。簡單的說法就是實現對數據表的Select，Insert，Update，Delete的操做。若是要加入ORM的元素，那麼就會包括對象和數據表之間的mapping，以及對象實體的持久化。

 

 2：業務邏輯層：主要負責對數據層的操做。也就是說把一些數據層的操做進行組合。業務邏輯層無疑是系統架構中體現核心價值的部分。它的關注點主要集中在業務規則的制定、業務流程的實現等與業務需求有關的系統設計，也便是說它是與系統所應對的領域（Domain）邏輯有關，不少時候，也將業務邏輯層稱爲領域層。業務邏輯層在體系架構中的位置很關鍵，它處於數據訪問層與表示層中間，起到了數據交換中承上啓下的做用。因爲層是一種弱耦合結構，層與層之間的依賴是向下的，底層對於上層而言是「無知」的，改變上層的設計對於其調用的底層而言沒有任何影響。若是在分層設計時，遵循了面向接口設計的思想，那麼這種向下的依賴也應該是一種弱依賴關係。於是在不改變接口定義的前提下，理想的分層式架構，應該是一個支持可抽取、可替換的「抽屜」式架構。正由於如此，業務邏輯層的設計對於一個支持可擴展的架構尤其關鍵，由於它扮演了兩個不一樣的角色。對於數據訪問層而言，它是調用者；對於表示層而言，它倒是被調用者。依賴與被依賴的關係都糾結在業務邏輯層上，如何實現依賴關係的解耦，則是除了實現業務邏輯以外留給設計師的任務。

 3：表示層：主要對用戶的請求接受，以及數據的返回，爲客戶端提供應用程序的訪問。位於最外層（最上層），離用戶最近。用於顯示數據和接收用戶輸入的數據，爲用戶提供一種交互式操做的界面。

  

F.面象對象與實例的結合：

咱們知道飯店將整個業務分解爲三部分來完成，每一部分各負其責，服務員只管接待顧客、向廚師傳遞顧客的需求；廚師只管烹炒不一樣口味、不一樣特點的美食；後勤工做人員只管提供美食原料；他們三者分工合做共同爲顧客提供滿意的服務。在飯店爲顧客提供服務期間，服務員、廚師、後勤工做人員，三者中任何一者的人員發生變化時都不會影響其餘倆者的正常工做，只對變化者進行從新調整便可正常營業。

咱們用三層結構開發的軟件系統於此相似，表示層只提供軟件系統與用戶交互的接口；業務邏輯層是表示層和數據訪問層之間的橋樑，負責數據處理和傳遞；數據訪問層只負責數據的存取工做。

 

 

 

思想上移與三層架構知識相結合：