簡析三層架構

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

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）：定義的username和password。

u層：向相應的文字框中輸入賬號和password

b層：推斷u層輸入的賬號和password是否存在。

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層，將這一變化反應出來。

舉例：

小菜和大鳥吃羊肉串的樣例。小菜和大鳥就是使用者，服務員為表示層（u層）。烤肉**為業務邏輯層（u層引用b層的方法或者引數），老闆娘為資料訪問層（d層），負責給烤肉**從庫房拿烤串。

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

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

1、開發者能夠僅僅關注整個結構中的當中某一層；

2、能夠非常easy的用新的實現來替換原有層次的實現。

3、能夠減少層與層之間的依賴；

4、有利於標準化；

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

6、結構更加的明白

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

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

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

簡析三層架構

簡析三層架構

簡析三層架構

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

相關推薦

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