三層架構初步瞭解

三層架構(3--tier-application)   什麼是三層架構？

三層架構通常是將整個業務應用劃分為: UI 介面層 BLL 商務邏輯層，DAL資料訪問層，Model 實體層 。區分層次的目的即為"高內聚,低耦合"的思想.

1 表現層(UI) ;通俗是展現給使用者的介面,及使用者在使用一個系統的時候他的所見所得.

2 商務邏輯層(BLL):針對具體問題操作,也可以說是對資料層的操作,對資料商務邏輯處理

3 資料訪問層(DAL) : 該層所做事物直接存取資料庫,針對資料庫的增,刪,改,查等.

為什麼要分層？

 

 三層結構主要是使項目結構更清楚，分工明確。有利於後期的為維護和升級。 他未必會提升效能，因為當子程式模組未執行結束時，主程式模組只能處於等待狀態。這說明將應用程式劃分層次，會帶來期執行速度上的一些損失。但從團隊開發效率角度上來講卻可以感受到大小不同的效果。

 

注意：三層不是．ＮＥＴ的專利，也不是專門用在資料庫上的技術，提示一種更加普適的架構設計理念。

 

各層作用？

 

為什麼要應用 商務邏輯層呢

 我們假設沒有一段登入代碼， 則可以這樣處理WEB程式，外觀層負責資料前台頁面的資料， 然後傳給中介層，中介層對資料進行處理，比如格式化 ，防止SQL注入等。這樣的資料在傳給訪問層然後與資料進行操作，比如與資料庫的使用者名稱和密碼匹配等等一些代碼。

 

中介層的用途很多， 比如： 驗證使用者輸入資料，緩衝從資料庫匯總讀取的資料等等，但是， 終結業務層的實際目的是將“資料訪問”的最基礎的儲存邏輯組合起來，形成一種商務規則。 例如： 在一個購物網站中有這樣的一個規則：
在該網站第一次購物的使用者，系統為其自動註冊，這樣的商務規則房子啊中介層最合適。

 

在“資料訪問層”中，最好不要出現任何的“商務邏輯”。也就是所，要保證"資料訪問"中的函數功能原子性。 即最小性和不可再分。”資料訪問層“只管負責儲存或讀取資料就可以了。

 

執行個體

 

對“三層結構”的深入理解——從一家小餐館說起

　　

一個“三層結構”的Web應用程式，就好象是一家小餐館。

n  表　現　層，所有的.aspx頁面就好像是這家餐館的菜譜。

n  中間業務層，就像是餐館的服務生。

n  資料訪問層，就像是餐館的大廚師傅。

n  而我們這些網站瀏覽者，就是去餐館吃飯的吃客了……

 

 

我們去一家餐館吃飯，首先得看他們的菜譜，然後喚來服務生，告訴他我們想要吃的菜肴。服務生記下來以後，便會馬上去通知大廚師傅要烹制這些菜。大廚師傅收到通知後，馬上起火燒菜。過了不久，服務生便把一道一道香噴噴的、熱氣騰騰的美味端到我們的桌位上——

而我們訪問一個基於asp.net技術的網站的時候，首先開啟的是一個aspx頁面。這個aspx頁面的背景程式會去調用中間業務層的相應函數來擷取結果。中間業務層又會去調用資料訪問層的相應函數來擷取結果。

對比一下：

從看，這兩個過程是否非常相似呢？

 

不同的地方只是在於，去餐館吃飯，需要吃客自己喚來服務生。而訪問一個asp.net網站，菜單可以代替吃客喚來服務生。在最後的返回結果上，把結果返回給aspx頁面，也就是等於把結果返回給瀏覽者了。

 

物件導向與實際的結合

 

　我們知道建立橋需要磚塊，應該是先準備好磚再來建造橋，不過為了講解上的連貫。我們先建立橋，建造的過程中需要用到磚塊在做。

Ｕ層其實就是橋，Ｃ層就是磚塊，Ｄ層是原料（石頭，沙子），這裡說為什麼Ｕ層要引用，依賴Ｄ層（而不是Ｕ層對Ｃ，Ｃ對Ｄ的層次），因為橋除了需要磚頭，其實也需要石頭和沙子。

實體圖為

 

規則

 三層結構的設計不是說把項目分層DAL,BLL,WebUI 三個模組就叫做三層了,下面幾個問題是項目裡面存在的問題

 

1 Uilayer 裡面只有少量(或者沒有) SQL語句或者預存程序調用,並且這些語句保證不會修改資料?

 

2 如果把UILayer 拿掉,你的項目還能在Interface/API的層次上提供所有功能麼?

 

3 你的DAL 可以一直到其他類似的項目麼?

 

4 三個模組,可以分別運行於不同的伺服器碼?

 

如果不是所有的答案都是YES,那麼項目還不能算是嚴格意義的三層程式,三層程式有一些需要約定的規則:

 

1 最關鍵的.UI層只能最為嚴格外殼,不能包含任何的BizLogic的處理過程

 

2 設計時應該從BLLc出發,BLL層在API上應該事先所有BIzLogic,一物件導向的方式

 

3 不管資料是一個簡單的SQLHerper 也好,還是帶有Mapping 過的Classes也好,應該在一定抽象程度上做到與系統無關.

 

4 不管使用COM+(Enterprise Server),還是remoting,還是WEBService之類的遠程對象技術,不管部署時候是不是真的分別部署到不同的伺服器上,最起碼在設計時候要這樣的考慮.更好的.還得考慮多台伺服器通過負載平衡作叢集.

 

 

        續篇為三層的詳細講解之實體類 與MVC