簡析三層架構

通過幾個問題，來初步的學習一下三層架構。

1、什麼是三層架構

2、應用場景——為什麼要用三層架構？

3、三層作用

4、各個層之間的關係

5、三層聯絡——引用

6、各層是如何呼叫的

7、三層和二層的對比

這幾個都是學習三層中最基本的問題，只有把這些問題搞清楚，才算是開啟了三層的門。

在軟體體系架構設計中，分層式結構是最常見，也是最重要的一種結構。三層從下至上分別為：資料訪問層（dal）、業務邏輯層（bll）、表示層（ui）。

表現層（ui）：展現給使用者的介面，即使用者在使用乙個系統的時候他的所見所得。

業務邏輯層（bll）：對資料層的操作，對資料業務邏輯處理。

資料訪問層（dal）：對資料庫的操作，資料的增添、刪除、修改、查詢等。

為什麼要用三層架構？

解耦！

不是所有的程式都需要使用三層架構，沒必要把簡單的問題複雜化。

先來說一下解耦，舉例：修電腦

電腦硬碟壞了？我們要做的就是換掉電腦硬碟

記憶體條壞了？只要換記憶體條就好

這些部件出現問題，都不會影響別的部件的正常使用，這個就是讓他們之間解耦。而和電腦不同的收音機，任何部件壞了，都會影響別的部件，這個體現的就是他們之間的耦合比較高。從這個例子裡面就可以看出解耦的好處，在三層中就是用的解耦的思想。

資料訪問層：從資料來源載入（select），寫入（insert/update），刪除（delete）資料。僅限於和資料來源打交道，讓程式簡單明瞭。

顯示層（ui）：向使用者展現特定業務資料，採集使用者的輸入資訊和操作。

原則：使用者至上，兼顧簡潔。

業務邏輯層（bll）：從dal中獲取資料，以供ui顯示用，從ui中獲取使用者指令和資料，執行業務邏輯、從ui中獲取使用者指令和資料，通過dal寫入資料來源。

ui->bll->ui:ui提供資料指令到業務邏輯，若自己可以搞定，則直接反饋到ui

ui->bll->dal->bll->dal:ui提供使用者指令和資料，提出請求並蒐集一定的資料bll，bll處理不了時，要訪問資料來源，則轉給dal

以登陸為例子，說明三層之間的引用關係：

實體層（entity）：定義的使用者名稱和密碼。

u層：向對應的文字框中輸入賬號和密碼

b層：判斷u層輸入的賬號和密碼是否存在。

d層：連線資料庫的語句，查詢資料庫。

他們之間的聯絡是通過實體傳遞來進行的，。

dal所在程式集不引用bll和ui

bll需要引用dal

ui直接引用dal，可能引用bll

非常忌諱互相引用，為了避免這個問題所有出現了實體層（業務資料模型，裡面的資料和資料庫的有所差異）

dal只提供基本的資料訪問，不包含任何業務相關的邏輯處理。ui只負責顯示和採集使用者操作，不包含任何的業務相關的邏輯處理，bll負責處理業務邏輯，通過獲取ui傳來的操作指令，決定執行業務邏輯，在需要訪問資料來源的時候直接交給dal處理。處理完成後，返回必要資料給ui。

表示層（ui）是使用者需要的介面，使用者有什麼需求都是在這個上面進行的改動，一旦有改動，首先u層向b層傳送使用者請求的說明，到達b層，b層再將u層的使用者請求傳送到d層，d層接受到使用者請求的指令後，對它進行處理，傳送資料反饋到b層，b層再發給u層，將這一變化反應出來。

舉例：

業務邏輯簡單，沒有真正的資料儲存層

抽象出業務邏輯層，當業務複雜到一定程度，當資料儲存到相應的儲存介質，資料儲存脫離開業務邏輯，把業務邏輯脫離開ui單獨存在，ui只需要呼叫業務訪問層，就可以實現跟使用者的互動。

1、開發人員可以只關注整個結構中的其中某一層；

2、可以很容易的用新的實現來替換原有層次的實現；

3、可以降低層與層之間的依賴；

4、有利於標準化；

5、利於各層邏輯的復用。

6、結構更加的明確

7、在後期維護的時候，極大地降低了維護成本和維護時間。

這幾點的中心思想就是「高內聚，低耦合」，類之間的耦合越弱，越有利於復用，乙個處在弱耦合的類被修改，不會對有關係的類造成波及。

以上是對三層的簡單認識，有的地方可能寫的不對，歡迎指出！

簡析三層架構

簡析三層架構

簡析三層架構

c mysql三層架構例項 三層架構例項

相關推薦

c mysql三層架構例項三層架構例項