我對三層架構的理解

本文導航：（排版還不錯吧，嘿嘿）

• 什麼是三層架構
  • 概念
• 三層介紹及其的職責
• 層之間的關係以及規則
  • 關係
  • 規則
• 三層架構的優缺點
  • 優點
  • 缺點
• 總結

什麼是三層架構概念

• 三層架構通常意義上的三層架構就是將整個業務應用劃分為：表現層（UI）、商務邏輯層（BLL）、資料訪問層（DAL）。區分層次的目的即為了“高內聚，低耦合”的思想。
• 提示：
  • 三層架構並不是只能是三層確切的說應該叫N-Tier,即多層架構。
  • 三層架構並不是簡單的將代碼分成三個層次就叫做三層。
  • 三層構架也並不是將程式部署在三個不同的地方上就叫做三層。

三層介紹及其的職責

• 展示層（UI）:主要負責獲得資料以及為使用者展現資料。例如應用程式中的form表單和B/S系統中的Web。
  • U層不得分擔Bll層的職責，除了一些簡單的判斷邏輯外不應該包含任何邏輯。

• 邏輯層（BLL）：重要負責邏輯處理，所有的邏輯應該都集中在這一層，交易處理也應該在邏輯層開啟。
  • 邏輯層無可厚非的是整個系統的核心，這一層可以分為很多子層，例如：把BLL層分為 Business Flow 和Busines Function 兩層，Business Function負責完成一些小的業務功能，而Busines Flow負責將小的商務邏輯組合成大的業務流。
  • 交易處理在BLL層開啟。因為B層負責處理的就是業務的邏輯，在這層開啟事務是最合理的。
  • 邏輯層的設計的好壞直接影響著系統的可擴充性、可維護性、可複用性。所以在邏輯層是使用設計模式最多的地方。
• 資料訪問層（DAL）：主要負責對資料庫的直接存取，向上層屏蔽資料庫差異。
  • 資料訪問層，一般也分為兩層，主要是將DAL層中的共有的操作抽象出一個類，例如：SqlDBHelper。

層之間的關係以及規則

• 下面是我畫的一張簡單的三層的ＵＭＬ包圖。

關係

• 系統各層次及層內部子層次之間都不得跨層調用。
• Entity 在各個層之間傳遞資料。
• 層之間的調用是單向的，由上而下的，即U調用B層，B層調用D層。

規則

• 層之間以實體類形式傳送參數，不要以變數形式傳送，以變數形式傳送不符合物件導向編程的思想。
• 在U層綁定到列表的資料採用DataSet或者DataTable形式返回，除次之外建議都以實體類或者實體集合的方式返回。因為DataSet有很多缺點。具體參考我的這篇部落格(弱類型資料集與強型別資料集 )
• 對於每一個資料庫表（Table）都有一個DB Entity class與之對應。
• 對於每一個DB Entity 都有一個DAL與之對應。
• DAL都實現同一個介面，這樣做是為了屏蔽資料庫差異，採用了抽象原廠模式+反射+設定檔的方式後，即使換了資料庫，也只是需要改寫設定檔就可以了。
• 除了D層其它層都不應該出現SQL語句。
• 設計應該盡量減少各層資料的傳遞。

三層架構的優缺點

優點

1. 降低維護成本，方便管理。
   • 採用分層的方式架構系統，使得系統各層的組件可以直接替換，更新，直接替換dll檔案就可以完成系統的更新。這樣就像給汽車換個輪胎一樣，你無需再把汽車送到廠家安裝，直接更換就可以了。因為組件之間是相互獨立的。
   • 邏輯主要在B層，就使得U層也就是用戶端不承擔太多的職責，即使更新商務邏輯，也無需修改用戶端，不用重新部署。
2. 對於不斷變化的系統有著先天的優勢。
   • 三層的設計就是按照物件導向的思想設計的，程式的可擴充性很強，針對不斷變化需求的系統有很大的優勢。如果不分層，只要改變一個小的地方，程式就得重新改寫編譯。
3. 屏蔽資料庫差異。
   • 按照三層架構設計的系統，對於資料庫的改變表示毫無壓力。三層中的D層一個很重要的職責就是屏蔽資料庫差異，抽象原廠模式+反射+設定檔使得更換資料庫變的簡單。即使資料庫變成了設計時沒有考慮在內的情況，也就是重新寫個DAL和DBHelper，而對於系統本身來說也無需重新編譯。
4. 適合大型項目及合作開發。
   • 三層架構使得合作開發成為可能，由於各層相互獨立，一個小組只需負責一小塊就可以。結構化的編程方法面對大型的項目會感到力不從心，因為結構化設計必定會使程式變的錯綜複雜。
5. 安全性。
   • 三層架構使得介面，商務邏輯，資料訪問相互獨立。可以在各層之間加密傳輸資料。商務邏輯層和資料庫訪問層可以部署在不同的伺服器上，甚至商務邏輯也可以分別部署在不同的伺服器上。這樣加上伺服器的防火牆使得系統更加安全。

缺點

1. 執行速度。
   • 由於層多了，由於各層之間要傳輸資料肯定比直接存取資料要慢。對於對速度要求苛刻的系統可能不是很適合。
2. 代碼量大。
   • 初次使用三層架構可能會感覺代碼量明顯增加，但是我覺得為了以後維護性方便，多寫點代碼是很值得的。
   • 三層架構各模組相互獨立，使得模組的複用性增強，例如一個公司做過一些類似的項目以後，再面對相同的項目就會花費更少的代價。這就是可複用性帶來的優勢。

總結

1. 層次的劃分並不是死的，沒有一種分法能夠適應所有的系統。學習三層就要瞭解它的實質瞭解分層的目的，與其說三層是一種架構不如說它是一種思想。
2. 三層架構是偉大的前人總結出的一種為了實現程式的可擴充性，可複用性，可讀性，可維護性以及方便合作開發等而總結出的一種架構。其實三層架構是物件導向發展的必然結果。為了實現上述的幾種特點，分層是必然的。
3. 分層沒有定法，但是只要奔著高內聚低耦合的物件導向思想去分，只要能夠滿足封裝、複用、擴充、移置等方面的要求就可以。
4. 學習分層就跟學習設計模式一樣，開始的時候總是從模仿開始，也會特別在意各種條條框框。但是這卻是一個不得不經曆的過程，學習分層不是為了學習分層本身，就像學習設計模式不是學習模式本身一樣，重要的是在這個過程中理解物件導向設計的魅力，體會前人思想的沉澱。無論是分層還是設計模式都是巨人，我們要做的就是站在它們的肩膀上然後成為巨人，超越巨人。