對“三層結構”的深入理解——怎樣纔算是一個符合“三層結構”的Web應用程序？

 

“三層結構”是什麼？

　　“三層結構”一詞中的“三層”是指：“表現層”、“中間業務層”、“數據訪問層”。其中：

n            表　現　層：位於最外層（最上層），離用戶最近。用於顯示數據和接收用戶輸入的數據，爲用戶提供一種交互式操作的界面。

n            中間業務層：負責處理用戶輸入的信息，或者是將這些信息發送給數據訪問層進行保存，或者是調用數據訪問層中的函數再次讀出這些數據。中間業務層也可以包括一些對“商業邏輯”描述代碼在裏面。

n            數據訪問層：僅實現對數據的保存和讀取操作。數據訪問，可以訪問數據庫系統、二進制文件、文本文檔或是XML文檔。

  

 

　　對依賴方向的研究將是本文的重點，數值返回方向基本上是沒有變化的。

 

在一個

　　如果只以分層的設計角度看，Duwamish7要比PetShop3.0複雜一些！而如果較爲全面的比較二者，PetShop3.0則顯得比較複雜。但我們先不討論這些，對PetShop3.0和Duwamish7的研究，並不是本文的重點。現在的問題就是：既然“三層結構”已經被分派到各自的項目中，那麼剩下來的項目是做什麼的呢？例如PetShop3.0中的“Model”、“IDAL”、“DALFactory”這三個項目，再例如Duwamish7中的“Common”項目，還有就是在Bincess.CN彬月論壇中的“Classes”、“DbTask”、這兩個項目。它們究竟是做什麼用的呢？

 

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

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

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

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

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

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

 

 

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

而我們訪問一個基於asp.net技術的網站的時候，首先打開的是一個aspx頁面。這個aspx頁面的後臺程序會去調用中間業務層的相應函數來獲取結果。中間業務層又會去調用數據訪問層的相應函數來獲取結果。 

爲什麼需要“三層結構”？——初探，就從數據庫的升遷開始

一個站點中，訪問數據庫的程序代碼散落在各個頁面中，就像夜空中的星星一樣繁多。這樣一動百動的維護，難度可想而知。最難以忍受的是，對這種維護工作的投入，是沒有任何價值的……

有一個比較好的解決辦法，那就是將訪問數據庫的代碼全部都放在一個程序文件裏。這樣，數據庫平臺一旦發生變化，那麼只需要集中修改這一個文件就可以了。我想有點開發經驗的人，都會想到這一步的。這種“以不變應萬變”的做法其實是簡單的“門面模式”的應用。如果把一個網站比喻成一家大飯店，那麼“門面模式”中的“門面”，就像是飯店的服務生，而一個網站的瀏覽者，就像是一個來賓。來賓只需要發送命令給服務生，然後服務生就會按照命令辦事。至於服務生經歷了多少辛苦才把事情辦成？那個並不是來賓感興趣的事情，來賓們只要求服務生儘快把自己交待事情辦完。我們就把ListLWord.aspx.cs程序就看成是一個來賓發出的命令，而把新加入的LWordTask.cs程序看成是一個飯店服務生，那麼來賓發出的命令就是：

“給我讀出留言板數據庫中的數據，填充到DataSet數據集中並顯示出來！”

而服務生接到命令後，就會依照執行。而PostLWord.aspx.cs程序，讓服務生做的是：

“把我的留言內容寫入到數據庫中！”

而服務生接到命令後，就會依照執行。這就是TraceLWord2！可以在CodePackage/TraceLWord2目錄中找到——

 

把所有的有關數據訪問的代碼都放到LWordTask.cs文件裏，LWordTask.cs程序文件如下：#001 using System; #002 using System.Data; #003 using System.Data.OleDb; // 需要操作 Access 數據庫 #004 using System.Web; #005 #006 namespace TraceLWord2 #007 { #008 /// <summary> #009 /// LWordTask 數據庫任務類 #010 /// </summary> #011 public class LWordTask #012 { #013 // 數據庫連接字符串 #014 private const string DB_CONN=@"PROVIDER=Microsoft.Jet.OLEDB.4.0; DATA Source=C:/DbFs/TraceLWordDb.mdb"; #015 #016 /// <summary> #017 /// 讀取數據庫表 LWord，並填充 DataSet 數據集 #018 /// </summary> #019 /// <param name="ds">填充目標數據集</param> #020 /// <param name="tableName">表名稱</param> #021 /// <returns>記錄行數</returns> #022 public int ListLWord(DataSet ds, string tableName) #023 { #024 string cmdText="SELECT * FROM [LWord] ORDER BY [LWordID] DESC"; #025 #026 OleDbConnection dbConn=new OleDbConnection(DB_CONN); #027 OleDbDataAdapter dbAdp=new OleDbDataAdapter(cmdText, dbConn); #028 #029 int count=dbAdp.Fill(ds, tableName); #030 #031 return count; #032 } #033 #034 /// <summary> #035 /// 發送留言信息到數據庫 #036 /// </summary> #037 /// <param name="textContent">留言內容</param> #038 public void PostLWord(string textContent) #039 { #040 // 留言內容不能爲空 #041 if(textContent==null || textContent=="") #042 throw new Exception("留言內容爲空"); #043 #044 string cmdText="INSERT INTO [LWord]([TextContent]) VALUES(@TextContent)"; #045 #046 OleDbConnection dbConn=new OleDbConnection(DB_CONN); #047 OleDbCommand dbCmd=new OleDbCommand(cmdText, dbConn); #048 #049 // 設置留言內容 #050 dbCmd.Parameters.Add(new OleDbParameter("@TextContent", OleDbType.LongVarWChar)); #051 dbCmd.Parameters["@TextContent"].Value=textContent; #052 #053 try #054 { #055 dbConn.Open(); #056 dbCmd.ExecuteNonQuery(); #057 } #058 catch #059 { #060 throw; #061 } #062 finally #063 { #064 dbConn.Close(); #065 } #066 } #067 } #068 }

如果將數據庫從Access 2000修改爲SQL Server 2000，那麼只需要修改LWordTask.cs這一個文件。如果LWordTask.cs文件太大，也可以把它切割成幾個文件或“類”。如果被切割成的“類”還是很多，也可以把這些訪問數據庫的類放到一個新建的“項目”裏。當然，原來的ListLWord.aspx.cs文件應該作以修改，LWord_DataBind函數被修改成：
#046 private void LWord_DataBind() #047 { #048 DataSet ds=new DataSet(); #049 (new LWordTask()).ListLWord(ds, @"LWordTable"); #050 #051 m_lwordListCtrl.DataSource=ds.Tables[@"LWordTable"].DefaultView; #052 m_lwordListCtrl.DataBind(); #053 }

原來的PostLWord.aspx.cs文件也應作以修改，Post_ServerClick函數被修改成：#048 private void Post_ServerClick(object sender, EventArgs e) #049 { #050 // 獲取留言內容 #051 string textContent=this.m_txtContent.Value; #052 #053 (new LWordTask()).PostLWord(textContent); #054 #055 // 跳轉到留言顯示頁面 #056 Response.Redirect("ListLWord.aspx", true); #057 } ...

應用中間業務層，實現“三層結構”

前面這種分離數據訪問代碼的形式，可以說是一種“三層結構”的簡化形式。因爲它沒有“中間業務層”也可以稱呼它爲“二層結構”。一個真正的“三層”程序，是要有“中間業務層”的，而它的作用是連接“外觀層”和“數據訪問層”。換句話說：“外觀層”的任務先委託給“中間業務層”來辦理，然後“中間業務層”再去委託“數據訪問層”來辦理……

那麼爲什麼要應用“中間業務層”呢？“中間業務層”的用途有很多，例如：驗證用戶輸入數據、緩存從數據庫中讀取的數據等等……但是，“中間業務層”的實際目的是將“數據訪問層”的最基礎的存儲邏輯組合起來，形成一種業務規則。例如：“在一個購物網站中有這樣的一個規則：在該網站第一次購物的用戶，系統爲其自動註冊”。這樣的業務邏輯放在中間層最合適：

 

 

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

　　在新TraceLWord3中，應用了“企業級模板項目”。把原來的LWordTask.cs，並放置到一個單一的項目裏，項目名稱爲：AccessTask。解決方案中又新建了一個名稱爲：InterService的項目，該項目中包含一個LWordService.cs程序文件，它便是“中間業務層”程序。

ASP.NET Web應用程序解決方案中，並不是說有aspx文件、有dll文件、還有數據庫，就是“三層結構”的Web應用程序，這樣的說法是不對的。也並不是說沒有對數據庫進行操作，就不是“三層結構”的。其實“三層結構”是功能實現上的三層。例如，在微軟的ASP.NET示範實例“Duwamish7”中，“表現層”被放置在“Web”項目中，“中間業務層”是放置在“BusinessFacade”項目中，“數據訪問層”則是放置在“DataAccess”項目中……而在微軟的另一個ASP.NET示範實例“PetShop3.0”中，“表現層”被放置在“Web”項目中，“中間業務層”是放置在“BLL”項目中，而“數據訪問層”則是放置在“SQLServerDAL”和“OracleDAL”兩個項目中。在Bincess.CN彬月論壇中，“表現層”是被放置在“WebForum”項目中，“中間業務（服務）層”是被放置在“InterService”項目中，而“數據訪問層”是被放置在“SqlServerTask”項目中。

0

0

0

(請您對文章做出評價)

　　從前面的程序段中可以看出，ListLWord.aspx.cs和PostLWord.aspx.cs這兩個文件已經找不到和數據庫相關的代碼了。只看到一些和LWordTask類有關係的代碼，這就符合了“設計模式”中的一種重要原則：“迪米特法則”。“迪米特法則”主要是說：讓一個“類”與儘量少的其它的類發生關係。在TraceLWord1中，ListLWord.aspx.cs這個類和OleDbConnection及OleDbDataAdapter都發生了關係，所以它破壞了“迪米特法則”。利用一個“中間人”是“迪米特法則”解決問題的辦法，這也是“門面模式”必須遵循的原則。下面就引出這個LWordTask門面類的示意圖：

 

 

ListLWord.aspx.cs和PostLWord.aspx.cs兩個文件對數據庫的訪問，全部委託LWordTask類這個“中間人”來辦理。利用“門面模式”，將頁面類和數據庫類進行隔離。這樣就作到了頁面類不依賴於數據庫的效果。以一段比較簡單的代碼來描述這三個程序的關係：
public class ListLWord { private void LWord_DataBind() { (new LWordTask()).ListLWord( ... ); } } public class PostLWord { private void Post_ServerClick(object sender, EventArgs e) { (new LWordTask()).PostLWord( ... ); } } public class LWordTask { public DataSet ListLWord(DataSet ds)... public void PostLWord(string textContent)... }

應用中間業務層，實現“三層結構”

前面這種分離數據訪問代碼的形式，可以說是一種“三層結構”的簡化形式。因爲它沒有“中間業務層”也可以稱呼它爲“二層結構”。一個真正的“三層”程序，是要有“中間業務層”的，而它的作用是連接“外觀層”和“數據訪問層”。換句話說：“外觀層”的任務先委託給“中間業務層”來辦理，然後“中間業務層”再去委託“數據訪問層”來辦理……

那麼爲什麼要應用“中間業務層”呢？“中間業務層”的用途有很多，例如：驗證用戶輸入數據、緩存從數據庫中讀取的數據等等……但是，“中間業務層”的實際目的是將“數據訪問層”的最基礎的存儲邏輯組合起來，形成一種業務規則。例如：“在一個購物網站中有這樣的一個規則：在該網站第一次購物的用戶，系統爲其自動註冊”。這樣的業務邏輯放在中間層最合適：

 

 

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

　　在新TraceLWord3中，應用了“企業級模板項目”。把原來的LWordTask.cs，並放置到一個單一的項目裏，項目名稱爲：AccessTask。解決方案中又新建了一個名稱爲：InterService的項目，該項目中包含一個LWordService.cs程序文件，它便是“中間業務層”程序。

ASP.NET Web應用程序解決方案中，並不是說有aspx文件、有dll文件、還有數據庫，就是“三層結構”的Web應用程序，這樣的說法是不對的。也並不是說沒有對數據庫進行操作，就不是“三層結構”的。其實“三層結構”是功能實現上的三層。例如，在微軟的ASP.NET示範實例“Duwamish7”中，“表現層”被放置在“Web”項目中，“中間業務層”是放置在“BusinessFacade”項目中，“數據訪問層”則是放置在“DataAccess”項目中……而在微軟的另一個ASP.NET示範實例“PetShop3.0”中，“表現層”被放置在“Web”項目中，“中間業務層”是放置在“BLL”項目中，而“數據訪問層”則是放置在“SQLServerDAL”和“OracleDAL”兩個項目中。在Bincess.CN彬月論壇中，“表現層”是被放置在“WebForum”項目中，“中間業務（服務）層”是被放置在“InterService”項目中，而“數據訪問層”是被放置在“SqlServerTask”項目中。

0

0

0

(請您對文章做出評價)