三層架構與養豬

　　為了更好地讓初學者輕鬆入門，這裡仍然採用趣味性的方式聊一些常用技術點，致力於.NET新手們的快速提高！知識都是普通的，關鍵是學習的思路。技術源於生活，技術原來可以這樣學。拋磚引玉而已。

　　階層在現實社會裡隨處可見。記得有個笑話講有個村長得意地向他老婆吹牛：“全中國只有四個人比我官大，鄉長、縣長、省長和國務院總理”。這個笑話也體現了真實社會中分層的現象。社會人群會分層，公司人員結構也會分層，樓房是分層的，甚至做包子的籠屜都是分層的。雖然分層的目的各有不同，但都是為解決某一問題而產生的。所以，分層架構其實是為瞭解決某一問題而產生的一種解決方案。

　　常用的三層架構設計

　　軟體系統最常用的一般會講到三層架構，其實就是將整個業務應用劃分為展示層、商務邏輯層、資料訪問層等，有的還要細一些，通過分解業務細節，將不同的功能代碼分散開來，更利於系統的設計和開發，同時為可能的變更提供了更小的單元，十分有利於系統的維護和擴充。

　　常見的三層架構基本包括如下幾個部分，1所示。

圖1 常見的三層架構

• 資料訪問層DAL：用於實現與資料庫的互動和訪問，從資料庫擷取資料或儲存資料到資料庫的部分。

• 
  

• 商務邏輯層BLL：商務邏輯層承上啟下，用於對上下互動的資料進行邏輯處理，實現營運目標。

• 
  

• 展示層Web：主要實現和使用者的互動，接收使用者請求或返回使用者請求的資料結果的展現，而具體的資料處理則交給商務邏輯層和資料訪問層去處理。

　　日常開發的很多情況下為了複用一些共同的東西，會把一些各層都用的東西抽象出來。如我們將資料對象實體和方法分離，以便在多個層中傳遞，例如稱為Model。一些共性的通用輔助類和工具方法，如資料校正、緩衝處理、加解密處理等，為了讓各個層之間複用，也單獨分離出來，作為獨立的模組使用，例如稱為Common。

　　此時，三層架構會演變為2所示的情況。

圖2 三層架構演變結果

• 業務實體Model：用於封裝實體類資料結構，一般用於映射資料庫的資料表或視圖，用以描述業務中客觀存在的對象。Model分離出來是為了更好地解耦，為了更好地發揮分層的作用，更好地進行複用和擴充，增強靈活性。

• 
  

• 通用類庫Common：通用的協助工具輔助類。

　　我們可以將對資料庫的共性操作抽象封裝成資料操作類（例如DbHelperSQL），以便更好地複用和使代碼簡潔。資料層底層使用通用資料庫操作類來訪問資料庫，最後完整的三層架構3 所示。

圖3 最後完整的三層架構

　　資料庫訪問類是對ADO.NET的封裝，封裝了一些常用的重複的資料庫操作。如微軟的企業庫SQLHelper.cs，動軟的DBUtility/DbHelperSQL等，為DAL提供訪問資料庫的協助工具輔助類。

　　通過以上分析，我們知道如今常用的三層架構是個什麼樣子，同時，我們也知道了三層架構在使用過程中的一些演化過程。那麼，為什麼要這樣分層，每層結構到底又起什麼作用呢？我們繼續往下看。

　　趣味理解：三層架構與養豬

　　豬肉價格一路高漲，據說有人養豬都發財致富奔小康了，程式員都說寫代碼沒前途了，還不如去養豬，不過，可別認為養豬沒有技術含量，比寫代碼容易，其實養豬也大有學問。為了更好地理解三層架構，就拿養豬來做個例子吧。俗話說：“沒吃過豬肉，還沒見過豬跑啊！”。

　　圖4 是三層架構化的養豬產業流水線趣味對此圖。

圖4 三層結構與養豬

　　對比圖3與圖4，我們可以看出：

• 資料庫好比豬圈，所有的豬有序地按地區或編號，存放在不同的豬欄裡。

• 
  

• DAL好比是屠宰場，把豬從豬圈取出來進行（處理）屠殺，按要求取出相應的部位（欄位），或者進行歸類整理（統計），形成整箱的豬肉（資料集），傳送給食品加工廠（BLL）。本來這裡都是同一伙人既管抓豬，又管殺豬的，後來覺得效率太低了，就讓一部分人出來專管抓豬了（DBUtility），根據要求來抓取指定的豬。

• 
  

• BLL好比食品加工廠，將豬肉深加工成各種可以食用的食品（業務處理）。

• 
  

• Web好比商場，將食品封裝成漂亮的可以銷售的產品，展現給顧客（UI表現層）。

• 
  

• 豬肉好比Model，無論是哪個廠（層），各個環節傳遞的本質都是豬肉，豬肉貫穿整個過程。

• 
  

• 通用類庫Common相當於工人使用的各種工具，為各個廠（層）提供諸如殺豬刀、繩子、剪刀、封裝箱、工具車等共用的常用工具（類）。其實，每個部門本來是可以自己製作自己的工具的，但是那樣會使效率比較低，而且也不專業，並且很多工作都會是重複的。因此，就專門有人開了這樣的工廠來製作這些工具，提供給各個工廠，有了這樣的分工，工廠就可以專心做自己的事情了。

　　當然，這裡只是形象的比喻，目的是為了讓大家更好地理解，實際的情況在細節上會有所不同。這個例子也只是說明了從豬圈到商場的單向過程，而實際三層開發中的資料互動是雙向的，可取可存。不過，據說有一種機器，把豬從這頭趕進去，另一頭就噗噗嚕嚕地出火腿腸了。如果火腿腸賣不了了，從那頭再放進去，這頭豬又原原本本出來了，科幻的機器吧，沒想到也可以和三層結構聯絡上。以上只是笑談，不過也使三層架構的基本概念更容易理解了。

　　上面談了那麼多，有人會問，我直接從資料庫取出內容直接操作不可以嗎？為什麼要這麼麻煩地用三層架構呢？三層架構到底有什麼好處呢？

　　不分層，當然可以，就好比整個過程不分屠宰場、加工場之類的，都在同一個場所（工廠）完成所有的活（屠殺、加工、銷售）。但為什麼要加工廠和商場呢？因為當規模比較大的時候，管理起來就會變得非常複雜，這樣的養殖方式已經無法滿足規模化的需要了。並且，從社會的發展來看，社會分工是人類進步的表現。社會分工的優勢就是讓適合的人做自己擅長的事情，使平均社會勞動時間大大縮短，生產效率顯著提高。能夠提供優質高效勞動產品的人才能在市場競爭中獲得高利潤和高價值。人盡其才，物盡其用最深刻的含義就是由社會分工得出的。軟體開發也一樣，做小項目的時候，分不分層確實看不出什麼差別，並且顯得更麻煩囉嗦了。但當項目變大和變複雜時，分層就顯示出它的優勢來了。所以分不分層要根據項目的實際情況而定，不能一概而論。

相關文檔：分層開發思想與小籠包