ASP.NET的三層架構(DAL,BLL,UI)

標籤：體系   位置   頁面   為什麼   需求   actor   win   組件   介面   

BLL   是商務邏輯層   Business   Logic   Layer   DAL   是資料訪問層   Data   Access   Layer          ASP.NET的三層架構(DAL,BLL,UI) 圖形表示三層結構. 其中web即為USL層web –> bll –> dal|           |          ||           V          |+–> model <—+一、三層體系架構　　1.展示層(USL)：主要表示WEB方式，也可以表示成WINFORM方式。如果邏輯層相當強大和完善，無論表現層如何定義和更改，邏輯層都能完善地提供服務。　　2.商務邏輯層(BLL)：主要是針對具體的問題的操作，也可以理解成對資料層的操作，對資料商務邏輯處理。如果說資料層是積木，那邏輯層就是對這些積木的搭建。　　3.資料訪問層(DAL)：主要是對未經處理資料(資料庫或者文字檔等存放資料的形式)的操作層，而不是指未經處理資料，也就是說，是對資料的操作，而不是資料庫，具體為商務邏輯層或展示層            提供資料服務.二、具體區分　　1.展示層：主要對使用者的請求接受，以及資料的返回，為用戶端提供應用程式的訪問。　　2.商務邏輯層：主要負責對資料層的操作，也就是說把一些資料層的操作進行組合。　　3.資料訪問層：主要看你的資料層裡面有沒有包含邏輯處理，實際上他的各個函數主要完成各個對資料檔案的操作，而不必管其他動作。三、總結　　三層結構是一種嚴格分層方法，即資料訪問層(DAL)只能被商務邏輯層(BLL)訪問，商務邏輯層只能被展示層(USL)訪問，使用者通過展示層將請求傳送給商務邏輯層，商務邏輯層完成相關商務規則和邏輯，並通過資料訪問層訪問資料庫獲得資料，然後按照相反的順序依次返回將資料顯示在展示層。有的三層結構還加了Factory、Model等其他層，實際都是在這三層基礎上的一種擴充和應用.一個簡單的三層結構程式一般包括DAL BLL WEB Model幾個項目，它們的相互參考關聯性如下1) WEB引用 BLL,Model2)BLL引用 DAL,Model3)DAL引用Model4)Model無引用 一提三層架構，大家都知道是表現層（UI），商務邏輯層（BLL）和資料訪問層（DAL），而且每層如何細分也都有很多的方法。但具體代碼怎麼寫，到底那些檔案算在哪一層，卻是模模糊糊的。下面用一個簡單的例子來帶領大家實戰三層架構的項目，這個例子只有一個功能，就是使用者的簡單管理。      首先建立一個空白解決方案，添加如下項目及檔案      1、添加ASP.NET Web Application項目，命名為UI，建立Web Form類型檔案User.aspx（含User.aspx.cs）      2、添加ClassLibrary項目，命名為BLL，建立Class類型檔案UserBLL.cs      3、添加ClassLibrary項目，命名為DAL，建立Class類型檔案UserDAL.cs。添加SQLHelper引用。（這個是微軟的資料訪問類，也可以不用，直接編寫所有的資料存取碼。我一般用自己寫的資料訪問類DataAccessHelper ）。      4、添加ClassLibrary項目，命名為Model，建立Class類型檔案UserModel.cs      5、添加ClassLibrary項目，命名為IDAL，建立Interface類型檔案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得到使用者詳細資料。      IsExist（UserInfo userInfo）判斷指定的username或email是否存在。      然後DAL也相應提供方法共BLL調用      SelectUser（UserInfo userInfo）      IsExist（UserInfo userInfo）      這樣BLL確實只起到了一個傳遞的作用。      但如果這樣做：      BLL.IsExist（Userinfo userinfo）      {      UerInfo user = DAL.SelectUser（User）；      return (userInfo.Id != null);      }      那麼DAL就無需實現IsExist()方法了，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，無需其它操作等等。本來想在文中加入一些具體的代碼的，但感覺不是很必要，如果大家覺得需要的話，我再補充吧。      總結：不要因為某個層對你來說沒用，或者實現起來特別簡單，就認為它沒有必要，或者摒棄它，或者挪作它用。只要進行了分層，不管是幾層，每一層都要有明確的目的和功能實現，而不要被實際過程所左右，造成同一類檔案位於不同層的情況發生。也不要出現同一層實現了不同的功能的情況發生。

 

ASP.NET的三層架構(DAL,BLL,UI)