.Net三層架構

 三層體系結構的概念

1. 用戶界面表示層(USL)
2. 業務邏輯層(BLL)
3. 數據訪問層(DAL)

BLL將USL與DAL隔開了，而且加入了業務規則

 

• 各層的做用
• 1：數據數據訪問層:主要是對原始數據（數據庫或者文本文件等存放數據的形式）的操做層，而不是指原始數據，也就是說，是對數據的操做，而不是數據庫,具體爲業務邏輯層或表示層提供數據服務．
  
  2：業務邏輯層:主要是針對具體的問題的操做，也能夠理解成對數據層的操做,對數據業務邏輯處理，若是說數據層是積木，那邏輯層就是對這些積木的搭建。
  
  3：表示層:主要表示WEB方式,也能夠表示成WINFORM方式,WEB方式也能夠表現成:aspx, 若是邏輯層至關強大和完善,不管表現層如何定義和更改,邏輯層都能完善地提供服務。

 

• 具體的區分方法
  
  1：數據數據訪問層:主要看你的數據層裏面有沒有包含邏輯處理，實際上他的各個函數主要完成各個對數據文件的操做。而沒必要管其餘操做。
  
  2：業務邏輯層:主要負責對數據層的操做。也就是說把一些數據層的操做進行組合。
  
  3：表示層:主要對用戶的請求接受，以及數據的返回，爲客戶端提供應用程序的訪問。

 

• 三層結構解釋
  
  所謂三層體系結構，是在客戶端與數據庫之間加入了一個中間層，也叫組件層。這裏所說的三層體系，不是指物理上的三層，不是簡單地放置三臺機器就是三層體系結構，也不只僅有B/S應用纔是三層體系結構，三層是指邏輯上的三層，即便這三個層放置到一臺機器上。 三層體系的應用程序將業務規則、數據訪問、合法性校驗等工做放到了中間層進行處理。一般狀況下，客戶端不直接與數據庫進行交互，而是經過COM/DCOM通信與中間層創建鏈接，再經由中間層與數據庫進行交換.
  
  開發人員能夠將應用的商業邏輯放在中間層應用服務器上，把應用的業務邏輯與用戶界面分開。在保證客戶端功能的前提下，爲用戶提供一個簡潔的界面。這意味着若是須要修改應用程序代碼，只須要對中間層應用服務器進行修改，而不用修改爲千上萬的客戶端應用程序。從而使開發人員能夠專一於應用系統核心業務邏輯的分析、設計和開發，簡化了應用系統的開發、更新和升級工做。

 

• 那麼爲何要應用「中間業務層」呢？舉些例子:
       咱們假設有一段登陸代碼，則能夠這樣處理Web程序，外觀層負責接收前臺頁面的數據，而後傳給中間層，中間層對數據進行處理，好比格式化，防SQL注入等等一些，這樣的數據再傳給數據訪問層而後與數據庫進行操做，好比與數據庫的用戶名和密碼匹配等等一些代碼。
  
  
  
• 「中間業務層」的用途有不少，例如：驗證用戶輸入數據、緩存從數據庫中讀取的數據等等……可是， 「中間業務層」的實際目的是將「數據訪問層」的最基礎的存儲邏輯組合起來，造成一種業務規則。例如：「在一個購物網站中有這樣的一個規則：在該網站第一次購物的用戶，系統爲其自動註冊」。這樣的業務邏輯放在中間層最合適： 

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

• ASP.NET中的三層結構說明
  
  完善的三層結構的要求是:修改表現層而不用修改邏輯層,修改邏輯層而不用修改數據層。不然你的應用是否是多層結構,或者說是層結構的劃分和組織上是否是有問題就很難說.不一樣的應用有不一樣的理解，這只是一個概念的問題．
•  
   
• 理解ASP.NET中的三層結構——爲何要分三層？
  
  咱們用三層結構主要是使項目結構更清楚，分工更明確，有利於後期的維護和升級。它未必會提高性能，由於當子程序模塊未執行結束時，主程序模塊只能處於等待狀態。這說明將應用程序劃分層次，會帶來其執行速度上的一些損失。但從團隊開發效率角度上來說卻能夠感覺到大不相同的效果。
  
  
  須要說明一下，三層結構不是.NET的專利，也不是專門用在數據庫上的技術。它是一種更加普適的架構設計理念。

 

 

此種架構要在數據庫設計上注意表之間的關係，盡力知足主與子的關係。在功能上對用戶要有必定的限制，不要表如今對於子表的刪除操做必定要慎重，以避免形成主表與子表的數據在邏輯上出現的主表的外鍵在子表中沒有相對應的值。

 

• 對於表的綜合查詢方法是：
  先對主表查詢，調用主表所對應的DL。再根據主表的記錄分別對每個子表進行查詢。將自表的查詢結果添加的主表後，造成一個大的查詢集合。
  對於表的操做（增刪改）：
  此時只對主表進行操做，調用主表對應的DL中的操做方法。
  RL層是邏輯判斷層，主要是對頁面上傳入的數據進行邏輯判斷。RL層之上就是UI

• 如何創建一個三層體系結構解決方案
  
  新建一個空白解決方案。而後：     
  「添加」－「新建項目」－「其餘項目」－「企業級模版項目」－「C#生成塊」－「數據訪問」（數據層，下簡稱D層）     
  「添加」－「新建項目」－「其餘項目」－「企業級模版項目」－「C#生成塊」－「業務規則」（業務層，下簡稱C層）     
  「添加」－「新建項目」－「其餘項目」－「企業級模版項目」－「C#生成塊」－「Web用戶界面」（界面層，下簡稱U層）     
  右鍵點「解決方案」－「項目依賴項」，設置U依賴於D、C，C依賴於D。     
  對U添加引用D、C，對C添加引用D。     
  到此爲止，一個三層的架子創建起來了。我上面說的很具體很「傻瓜」，知道的人以爲我廢話，其實我這段時間很強烈的感受到很是多的人其實對這個簡單的過程徹底不瞭解。雖然不反對建2個「空項目」和1個「Asp    net    Web應用程序項目」也能夠做爲3層的框架，並且至關多的人認爲其實這些「企業級模板項目」其實就是個空項目，這是一個誤區。沒錯，企業級模板項目你從解決方案資源管理器裏看它是個什麼也沒有的，可是你能夠用記事本打開項目文件，看見不一樣了吧？？有些東西在背後，你是看不見的，不過系統已經作好了。也就是說，若是你在C層裏的某個類裏「using    System    Data    SqlClineit」，或者使用一個SqlConnection對象，編譯時候不會出錯，可是會在「任務列表」裏生成一些「策略警告」，警告你在C層裏不要放應該放在D層的東西（雖然就程序來講沒錯，可是可讀性可維護性就打了折扣）而這種功能，空項目是沒法給你的。

• 在新TraceLWord3中，應用了「企業級模板項目」。把原來的LWordTask.cs，並放置到一個單一的項目裏，項目名稱爲：AccessTask。解決方案中又新建了一個名稱爲：InterService的項目，該項目中包含一個LWordService.cs程序文件，它即是「中間業務層」程序。爲了避免重複命名，TraceLWord3的網站被放置到了WebUI項目中。更完整的代碼，能夠在CodePackage/TraceLWord3目錄中找到——     

• 面象對象與實際的結合
  
  
• 咱們知道建橋須要磚塊，應該是先準備好磚再來建橋，不過爲了講解上的順序性和連貫性，簡單性。咱們先建橋，建的過程當中須要磚塊再現作，這樣就不會多出來「橋不須要的東西」。注意在實際中，仍是應該先準備磚塊。
       
  U層其實就是橋，C層是磚塊，D層是原料（石頭、沙子）。這也解釋前面爲何U層要引用、依賴D層（而不是U對C，C對D的層次），由於橋除了須要磚頭，其實也須要石頭沙子。

 

• 「三層結構」的缺點

• 有些網友在讀完這篇文章前做以後，對我提出了一些質疑，這提醒我文章至此尚未說起「三層結構」的缺點。「三層結構」這個詞眼彷佛一直都很熱門，究其緣由，或許是這種開發模式應用的比較廣泛。可是「三層結構」卻並非百試百靈的「萬靈藥」，它也存在着缺點。下面就來講說它的缺點……

  「三層結構」開發模式的一個很是明顯的缺點就是其執行速度不夠快。固然這個「執行速度」是相對於非分層的應用程序來講的。從文中所給出的時序圖來看，也明顯的暴露了這一缺點。TraceLWord1和TraceLWord2沒有分層，直接調用的ADO.NET所提供的類來獲取數據。可是，TraceLWord6確要通過屢次調用才能獲取到數據。在子程序模塊程序沒有返回時，主程序模塊只能處於等待狀態。因此在執行速度上，留言板的版本越高，排名卻越靠後。「三層結構」開發模式，不適用於對執行速度要求過於苛刻的系統，例如：在線訂票，在線炒股等等……它比較擅長於商業規則容易變化的系統。

  「三層結構」開發模式，入門難度夠高，難於理解和學習。這是對於初學程序設計的人來講的。以這種模式開發出來的軟件，代碼量一般要稍稍多一些。這每每會令初學者淹沒在茫茫的代碼之中。望之生畏，對其產生反感，也是能夠理解的……

  其實，不管哪種開發模式或方法，都是有利有弊的。不會存在一種「萬用法」能夠解決任何問題。因此「三層結構」這個詞眼也不會是個例外！是否採用這個模式進行系統開發，要做出比較、權衡以後才能夠。切忌濫用!

 

• 參與資料
  
  

1. MainDoc.rar    （《淺談「三層結構」原理與用意》1.30M)      
   
   http://www.bincess.cn/Downloads/MainDoc.rar     
   
   
2. petshop 4.0的體系結構（只是稍微看了一下，瞭解一下結構）
   
   
   簡介：PetShop隨着版本的不斷更新，至如今基於.Net 2.0的PetShop4.0爲止，整個設計逐漸變得成熟而優雅，並且有不少能夠借鑑之處。PetShop是一個小型的項目，系統架構與代碼都比較簡單，卻也凸現了許多很有價值的設計與開發理念。
   下載地址: http://msdn.microsoft.com/en-us/library/aa479070.aspx
   PetShop架構設計
   三層」應用結構：數據訪問層、業務邏輯層（領域層）、表示層
   分層的設計的特色：
   結構清晰、耦合度低
   便於系統的擴展
   利於開發任務同步進行
   下降了必定的性能

   .Net    PetShop    4.0    配置文件屬性管理

   http://blog.csdn.net/fengfangfang/archive/2006/09/07/1189061.aspx       
   
   .Net    PetShop    4.0    緩存處理       
   http://blog.csdn.net/fengfangfang/archive/2006/09/06/1185077.aspx       
   
   .Net    PetShop    4.0    消息處理       
   http://blog.csdn.net/fengfangfang/archive/2006/09/08/1194896.aspx       
   
   每一個功能都使用了工廠模式 
   

    

3. 參考了Duwamish
   
4. Web Search