簡析三層架構，簡析三層

簡析三層架構，簡析三層
三層架構——3-tier architecture通過幾個問題，來初步的學習一下三層架構。
1、什麼是三層架構2、應用情境——為什麼要用三層架構？3、三層作用4、各個層之間的關係5、三層聯絡——引用6、各層是如何調用的7、三層和二層的對比這幾個都是學習三層中最基本的問題，只有把這些問題搞清楚，才算是開啟了三層的門。

1、什麼是三層架構

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

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

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

資料訪問層（DAL）：對資料庫的操作，資料的增添、刪除、修改、尋找等。

2、應用情境——為什麼要用三層架構？

為什麼要用三層架構？

解耦！

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

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

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

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

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

 

 

3、三層作用

資料訪問層：從資料來源載入（Select），寫入（Insert/Update），刪除（Delete）資料。僅限於和資料來源打交道，讓程式簡單明了。

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

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

商務邏輯層（BLL）：從DAL中擷取資料，以供UI顯示用，從UI中擷取使用者指令和資料，執行商務邏輯、從UI中擷取使用者指令和資料，通過DAL寫入資料來源。

 

4、各個層之間的關係：

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

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

5、三層聯絡——引用

以登陸為例子，說明三層之間的參考關聯性：

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

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

B層：判斷U層輸入的帳號和密碼是否存在。

D層：串連資料庫的語句，查詢資料庫。

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

 

DAL所在程式集不引用BLL和UI

BLL需要引用DAL

UI直接引用DAL，可能引用BLL

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

應用原則：

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

 

6、各層是如何調用的

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

 

舉例：

小菜和大鳥吃羊肉串的例子，小菜和大鳥就是使用者，服務員為展示層（U層），烤肉師父為商務邏輯層（U層引用B層的方法或者參數），老闆娘為資料訪問層（D層），負責給烤肉師父從庫房拿烤串。大鳥點了羊肉串5串（參數），服務員把羊肉串5串（參數傳遞）傳遞給烤肉師父（資料請求），烤肉師父再傳遞給老闆娘（對參數進行處理），老闆娘得到請求後，拿羊肉串給烤肉師父（資料反饋），烤肉師父將烤好的羊肉串給服務員（資料反饋），服務員再將5串羊肉串給大鳥（U層展現出來），他們之間通過調用來實現聯絡。

 

7、三層PK二層二層架構：

商務邏輯簡單，沒有真正的資料存放區層

三層架構：

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

三層的好處：

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

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

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

4、有利於標準化；

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

6、結構更加的明確

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

 

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

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

 

NET三層架構解析一：什是三層架構

所謂三層架構，是在用戶端與資料庫之間加入了一個“中介層”，也叫組件層。這裡所說的三層體系，不是指物理上的三層，不是簡單地放置三台機器就是三層體繫結構，也不僅僅有B/S應用才是三層體繫結構，三層是指邏輯上的三層，即使這三個層放置到一台機器上。在項目開發的過程中，有時把整個項目分為三層架構，其中包括：展示層(UI)、商務邏輯層(BLL)和資料訪問層(DAL)。三層的作用分別如下：展示層：為使用者提供互動操作介面，這一點不論是對於Web還是WinForm都是如此，就是使用者介面操作。我們網站展示給使用者看的介面。商務邏輯層：負責關鍵業務的處理和資料的傳遞。複雜的邏輯判斷和涉及到資料庫的資料驗證都需要在此做出處理。根據傳入的值返回使用者想得到的值，或者處理相關的邏輯。資料訪問層：見名知意，負責資料庫資料的訪問。主要為商務邏輯層提供資料，根據傳入的值來操作資料庫，增、刪、改或者其它。以下我簡單介紹下一個使用者管理模組:為了整個項目的開發方便，我們在項目中會建幾個類庫SQLHelper,BLL,DAL,Model和一個Web網站。為了命名清晰，我們可以這樣命名這個三個工程（即在解決方案裡添加的類庫）:商務邏輯層(BusinessLogicLayer)：BLL，命名空間預設設定為BLL資料訪問層(DataAccessLayer):DAL,命名空間預設設定為DALSQL協助類：SQLHelper,命名空間預設設定為SQLHelper另外我們為了資料傳遞的方便，通常再添加一個類庫，這個類庫是貫穿於整個三層架構中的。即實體類。通常命名為Model,命名空間預設值設定為：Models。其中封裝的每個類都對應一個實體，通常就是資料庫中的一個表。如資料庫中的使用者表（custom）封裝為（custom），將表中的每個欄位都封裝成共有的屬性。這樣三層架構的搭建就基本完成了。這三層有著非常強的依賴關係：展示層 ← 商務邏輯層 ← 資料訪問層他們之間的資料傳遞是雙向的，並且通常藉助實體類傳遞資料。那麼三層架構都有哪些優點呢：1、易於項目的修改和維護。在項目的開發過程中或者開發後的升級過程中，甚至在項目的移植過程中。這種三層架構是非常方便的。比如項目從Web移植到Form，我們只需要將展示層重新做一遍就可以了。其餘兩層不用改動，只需添加到現有項目就可以了。如果不採用這種架構，只是將代碼寫到展示層。那麼所有的編碼幾乎都要重新來了。2、易於擴充。在功能的擴充上同樣如此，如有功能的添加只需把原有的類庫添加方法就可了3、易於代碼的重用。這一點就不用解釋了。4、易於分工協作開還可以加個介面類庫Iinterface, 加入設計模式，使你的代碼靈活性更好源碼天空，品質更高。其實，當我們做一個項目時，我們應該先考慮一下這個項目是不是應該應用三層/多層設計時, 先得考慮下是不是真的需要?
 
NET三層架構解析一：什是三層架構

所謂三層架構，是在用戶端與資料庫之間加入了一個中介層，也叫組件層。這裡所說的三層體系，不是指物理上的三層，不是簡單地放置三台機器就是三層體繫結構，也不僅僅有B/S應用才是三層體繫結構，三層是指邏輯上的三層，即使這三個層放置到一台機器上。在項目開發的過程中，有時把整個項目分為三層架構，其中包括：展示層(UI)、商務邏輯層(BLL)和資料訪問層(DAL)。三層的作用分別如下：展示層：為使用者提供互動操作介面，這一點不論是對於Web還是WinForm都是如此，就是使用者介面操作。我們網站展示給使用者看的介面。商務邏輯層：負責關鍵業務的處理和資料的傳遞。複雜的邏輯判斷和涉及到資料庫的資料驗證都需要在此做出處理。根據傳入的值返回使用者想得到的值，或者處理相關的邏輯。資料訪問層：見名知意，負責資料庫資料的訪問。主要為商務邏輯層提供資料，根據傳入的值來操作資料庫，增、刪、改或者其它。以下我簡單介紹下一個使用者管理模組:為了整個項目的開發方便，我們在項目中會建幾個類庫SQLHelper,BLL,DAL,Model和一個Web網站。為了命名清晰，我們可以這樣命名這個三個工程（即在解決方案裡添加的類庫）:商務邏輯層(BusinessLogicLayer)：BLL，命名空間預設設定為BLL資料訪問層(DataAccessLayer):DAL,命名空間預設設定為DALSQL協助類：SQLHelper,命名空間預設設定為SQLHelper另外我們為了資料傳遞的方便，通常再添加一個類庫，這個類庫是貫穿於整個三層架構中的。即實體類。通常命名為Model,命名空間預設值設定為：Models。其中封裝的每個類都對應一個實體，通常就是資料庫中的一個表。如資料庫中的使用者表（custom）封裝為（custom），將表中的每個欄位都封裝成共有的屬性。這樣三層架構的搭建就基本完成了。這三層有著非常強的依賴關係：展示層 ← 商務邏輯層 ← 資料訪問層他們之間的資料傳遞是雙向的，並且通常藉助實體類傳遞資料。1、易於項目的修改和維護。在項目的開發過程中或者開發後的升級過程中，甚至在項目的移植過程中。這種三層架構是非常方便的。比如項目從Web移植到Form，我們只需要將展示層重新做一遍就可以了。其餘兩層不用改動，只需添加到現有項目就可以了。如果不採用這種架構，只是將代碼寫到展示層。那麼所有的編碼幾乎都要重新來了。2、易於擴充。在功能的擴充上同樣如此，如有功能的添加只需把原有的類庫添加方法就可了3、易於代碼的重用。這一點就不用解釋了。4、易於分工協作開還可以加個介面類庫Iinterface, 加入設計模式，使你的代碼靈活性更好源碼天空其實，當我們做一個項目時，我們應該先考慮一下這個項目是不是應該應用三層/多層設計時, 先得考慮下是不是真的需要? 實際上大部分程式就開個WebApplication就足夠了, 完全沒必要作的這麼複雜. 而多層結構, 是用於解決真正複雜的項目需求的。