一提三層架構，大家都知道是表現層（ui），業務邏輯層（bll）和資料訪問層（dal），而且每層如何細分也都有很多的方法。但具體**怎麼 寫，到底那些檔案算在哪一層，卻是模模糊糊的。下面用乙個簡單的例子來帶領大家實戰三層架構的專案，這個例子只有乙個功能，就是使用者的簡單管理。
首先建立乙個空白解決方案，新增如下專案及檔案
2、新增classlibrary專案，命名為bll，新建class型別檔案userbll.cs
3、新增classlibrary專案，命名為dal，新建class型別檔案userdal.cs。新增sqlhelper引用。（這個是微軟的資料訪 問類，也可以不用，直接編寫所有的資料訪問**。我一般用自己寫的資料訪問類dataaccesshelper ）。
4、新增classlibrary專案，命名為model，新建class型別檔案usermodel.cs
5、新增classlibrary專案，命名為idal，新建inte***ce型別檔案iuserdal.cs
6、新增classlibrary專案，命名為classfactory
相信大家已經看出來了，這個和petshop的示例沒什麼區別，而且更簡單，因為在下也是通過petshop學習三層架構的。但一些朋友對於這幾個專案所處的層次，以及它們之間的關係，可能比較模糊，這裡逐個說明一下：
1、user.aspx和user.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才算有了真正的用途。
2、newbll.cs
新增如下方法：
public ilist
getusers()：返回所有的使用者資訊列表
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中也就有了邏輯處理的**。
3、usermodel.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的支援就行，然後前台增加會員卡一項內容的表現與處理即可。
4、userdal.cs
public ilist
selectusers()：返回所有的使用者資訊列表
public userinfo selectuser(int userid)：返回指定使用者的相信資訊
public bool insertuser(userinfo user)：新增使用者資訊
public bool updateuser(userinfo user)：更新使用者資訊
public void deleteuser(int userid)：移除使用者資訊
很多人最鬧不清的就是資料訪問層，到底那部分才算資料訪問層呢？有些認為資料庫就是資料訪問層，這是對定義沒有搞清楚，dal是資料訪問層而不是資料儲存 層，因此資料庫不可能是這一層的。也有的把sqlhelper（或其同類作用的元件）作為資料訪問層，它又是乙個可有可無的東西，sqlhelper的作 用是減少重複性編碼，提高編碼效率，因此如果我習慣在乎效率或使用乙個非資料庫的資料來源時，可以丟棄sqlhelper，乙個可以隨意棄置的部分，又怎麼 能成為三層架構中的一層呢。
可以這樣定義：與資料來源操作有關的**，就應該放在資料訪問層中，屬於資料訪問層
5、iuserdal
資料訪問層介面，這又是乙個可有可無的東西，因為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 三層架構
user.aspx和user.aspx.cs 這兩個檔案 以及檔案所屬的專案，下面也是如此，不再重複強調了 都屬於表現層部分。user.aspx比較好理解，因為它就是顯示頁面了。user.aspx.cs有些人覺得不應該算，而是要划到業務邏輯層中去。如果不做分層的話，那麼讓user.aspx.cs來處...
C 三層架構程式設計
所謂三層體系結構，是在客戶端與資料庫之間加入了乙個 中間層 也叫元件層。這裡所說的三層體系，不是指物理上的三層，不是簡單地放置三颱機器就是三層體系結構，也不僅僅有b s應用才是三層體系結構，三層是指邏輯上的三層，即使這三個層放置到一台機器上。通用三層結構軟體模型如下圖所示。使用者介面層 user i...