C 三層架構

2022-09-19 07:36:08 字數 4624 閱讀 2537

user.aspxuser.aspx.cs

這兩個檔案(以及檔案所屬的專案,下面也是如此,不再重複強調了)都屬於表現層部分。user.aspx比較好理解,因為它就是顯示頁面了。user.aspx.cs有些人覺得不應該算,而是要划到業務邏輯層中去。如果不做分層的話,那麼讓user.aspx.cs來處理業務邏輯,甚至運算元據庫都沒什麼問題,但是做分層的話,這樣就不應該了。在分層結構中,user.aspx.cs僅應該處理與顯示有關的內容,其它部分都不應該涉及。

舉例:我們實現用列表方式顯示使用者的功能,那麼提取資訊的工作是由bll來做的,ui(本例中是user.aspx.cs)呼叫bll得到userinfo後,通過**繫結到user.aspx的資料控制項上,就實現了列表的顯示。在此過程中user.aspx.cs對ui沒有起到什麼作用,僅是用來傳遞資料,而且因為實際編碼中大部分情況都是如此的實現,所以使有些人覺得user.aspx.cs不應該算ui,而應該併入bll負責邏輯處理。繼續往下看,這時提出了乙個新需求,要求在每個使用者的前面加乙個圖示,生動地表現出使用者的性別,而且不滿18歲的用兒童圖示表示。這個需求的實現,就輪到user.aspx.cs來做了,這種情況下user.aspx.cs才算有了真正的用途。

2newbll.cs

新增如下方法:

public ilistgetusers():返回所有的使用者資訊列表

public userinfo getuser(int userid):返回指定使用者的詳細資訊

public bool adduser(userinfo user):新增使用者資訊

public bool changeuser(userinfo user):更新使用者資訊

public void removeuser(int userid):移除使用者資訊

此檔案就屬於業務邏輯層了,專門用來處理與業務邏輯有關的操作。可能有很多人覺得這一層唯一的用途,就是把表現層傳過來的資料**給資料層。這種情況確實很多,但這只能說明專案比較簡單,或者專案本身與業務的關係結合的不緊密(比如當前比較流行的mis),所以造成業務層無事可做,只起到了乙個**的作用。但這不代表業務層可有可無,隨著專案的增大,或者業務關係比較多,業務層就會體現出它的作用來了。

此處最可能造成錯誤的,就是把資料操作**劃在了業務邏輯層,而把資料庫作為了資料訪問層。

舉例:有些朋友感覺bll層意義不大,只是將dal的資料提上來就**給了ui,而未作任何處理。看一下這個例子

bll層

selectuser(userinfo userinfo)根據傳入的username或email得到使用者詳細資訊。

i***ist(userinfo userinfo)判斷指定的username或email是否存在。

然後dal也相應提供方法共bll呼叫

selectuser(userinfo userinfo)

i***ist(userinfo userinfo)

這樣bll確實只起到了乙個傳遞的作用。

但如果這樣做:

bll.i***ist(userinfo userinfo)

那麼dal就無需實現i***ist()方法了,bll中也就有了邏輯處理的**。

3usermodel.cs

實體類,這個東西,大家可能覺得不好分層。包括我以前在內,是這樣理解的:ui?àmodel?àbll?àmodel?àdal,如此則認為model在各層之間起到了乙個資料傳輸的橋梁作用。不過在這裡,我們不是把事情想簡單,而是想複雜了。

model是什麼?它什麼也不是!它在三層架構中是可有可無的。它其實就是物件導向程式設計中最基本的東西:類。乙個桌子是乙個類,一條新聞也是乙個類,int、string、doublie等也是類,它僅僅是乙個類而已。

這樣,model在三層架構中的位置,和int,string等變數的地位就一樣了,沒有其它的目的,僅用於資料的儲存而已,只不過它儲存的是複雜的資料。所以如果你的專案中物件都非常簡單,那麼不用model而直接傳遞多個引數也能做成三層架構。

那為什麼還要有model呢,它的好處是什麼呢。下面是思考乙個問題時想到的,插在這裡:

model在各層引數傳遞時到底能起到做大的作用?

在各層間傳遞引數時,可以這樣:

adduser(userid,username,userpassword,…,)

也可以這樣:

adduser(userinfo)

這兩種方法那個好呢。一目了然,肯定是第二種要好很多。

什麼時候用普通變數型別(int,string,guid,double)在各層之間傳遞引數,什麼使用model傳遞?下面幾個方法:

selectuser(int userid)

selectuserbyname(string username)

selectuserbyname(string username,string password)

selectuserbyemail(string email)

selectuserbyemail(string email,string password)

可以概括為:

selectuser(userid)

selectuser(user)

這裡用user這個model物件囊括了username,password,email這三個引數的四種組合模式。userid其實也可以合併到user中,但專案中其它bll都實現了帶有id引數的介面,所以這裡也保留這一項。

傳入了userinfo,那如何處理呢,這個就需要按照先後的順序了,有具體**決定。

這裡按這個順序處理

首先看是否同時具有username和password,然後看是否同時具有email和password,然後看是否有username,然後看是否有email。依次處理。

這樣,如果以後增加乙個新內容,會員卡(number),則無需更改介面,只要在dal的**中增加對number的支援就行,然後前台增加會員卡一項內容的表現與處理即可。

4userdal.cs

public ilistselectusers():返回所有的使用者資訊列表

public userinfo selectuser(int userid):返回指定使用者的相信資訊

public bool insertuser(userinfo user):新增使用者資訊

public bool updateuser(userinfo user):更新使用者資訊

public void deleteuser(int userid):移除使用者資訊

很多人最鬧不清的就是資料訪問層,到底那部分才算資料訪問層呢?有些認為資料庫就是資料訪問層,這是對定義沒有搞清楚,dal是資料訪問層而不是資料儲存層,因此資料庫不可能是這一層的。也有的把sqlhelper(或其同類作用的元件)作為資料訪問層,它又是乙個可有可無的東西,sqlhelper的作用是減少重複性編碼,提高編碼效率,因此如果我習慣在乎效率或使用乙個非資料庫的資料來源時,可以丟棄sqlhelper,乙個可以隨意棄置的部分,又怎麼能成為三層架構中的一層呢。

可以這樣定義:與資料來源操作有關的**,就應該放在資料訪問層中,屬於資料訪問層

5iuserdal

資料訪問層介面,這又是乙個可有可無的東西,因為petshop中帶了它和classfactory類工廠,所以有些專案不論需不需要支援多資料來源,都把這兩個東西做了進來,有的甚至不建classfactory而只建了idal,然後「iuserdal iuserdal = new userdal();」,不知意義何在。這就完全是畫虎不成反類犬了。

許多人在這裡有乙個誤解,那就是以為存在這樣的關係:bll?àidal?àdal,認為idal起到了bll和dal之間的橋梁作用,bll是通過idal來呼叫dal的。但實際是即使你如此編碼:「iuserdal iuserdal = classfacotry.createuserdal();」,那麼在執行「iuserdal.selectusers()」時,其實還是執行的userdal例項,而不是iuserdal例項,所以idal在三層中的位置是與dal平級的關係。

通過上面的介紹,基本上將三層架構的層次結構說明了。其實,本人有乙個判斷三層架構是否標準的方法,那就是將三層中的任意一層完全替換,都不會對其它兩層造成影響,這樣的構造基本就符合三層標準了(雖然實現起來比較難^_^)。例如如果將專案從b/s改為c/s(或相反),那麼除了ui以外,bll與dal都不用改動;或者將sqlserver改為oracle,只需替換sqlserverdal到oracledal,無需其它操作等等。本來想在文中加入一些具體的**的,但感覺不是很必要,如果大家覺得需要的話,我再補充吧。

總結:不要因為某個層對你來說沒用,或者實現起來特別簡單,就認為它沒有必要,或者摒棄它,或者挪作它用。只要進行了分層,不管是幾層,每一層都要有明確的目的和功能實現,而不要被實際過程所左右,造成同一類檔案位於不同層的情況發生。也不要出現同一層實現了不同的功能的情況發生。

C 三層架構

c 學了個皮毛加上太久沒用,只會像個廢物一樣拖控制項,直到昨天看到大佬的操作,現在開始從頭學習!大部分是學習別人的成果,站在巨人的肩膀上!一 為什麼要用三層架構?三層結構符合 高內聚 低耦合 的特點,每個層職責明確。利用分層,降低了層間依賴,使系統的耦合更加鬆散,從而使系統更加容易維護和復用。分層架...

C 三層架構程式設計

所謂三層體系結構,是在客戶端與資料庫之間加入了乙個 中間層 也叫元件層。這裡所說的三層體系,不是指物理上的三層,不是簡單地放置三颱機器就是三層體系結構,也不僅僅有b s應用才是三層體系結構,三層是指邏輯上的三層,即使這三個層放置到一台機器上。通用三層結構軟體模型如下圖所示。使用者介面層 user i...

C 三層架構例項

對於三層的概念查也查了,看也看了,下面是我找的乙個關於三層的簡單例項,真正看一下它是如何具體實現的.我們先來一起看看 實體類 model 實質 實體類就是在完成資料庫與實體類對應的功能,乙個類是一張表,乙個屬性是乙個字段!using system using system.collections.g...