三層架構——U層、B層、D層，層層深入

引用一張圖片來表示三層系統的分階層：

表現層（UI）：通俗地講就是展現給使用者的介面，即使用者在使用一個系統的時候他的所見所得。

商務邏輯層（BLL）：針對具體問題的操作，也可以說是對資料層的操作，對資料商務邏輯處理。

資料訪問層（DAL）：該層所做事務直接操作資料庫，針對資料的增刪改查等。

下面這張圖是對各個層作用的解釋:

    但每個系統不只有這三個部分，還包括業務實體和一些通用類庫。日常開發的很多情況下為了複用一些共同的東西，會把一些各層都用的東西抽象出來。如我們將資料對象實體和方法分離，以便在多個層中傳遞，例如稱為Model。Model用於封裝實體類資料結構，一般用於映射資料庫的資料表或視圖，用以描述業務中客觀存在的對象。而一些共性的通用輔助類和工具方法，如資料校正、緩衝處理、加解密處理等，為了讓各個層之間複用，也單獨分離出來，作為獨立的模組使用，例如稱為Common。

    所以，系統結構成為下面這張圖的樣子：

運用三層的思想開發系統有很多好處，同時也有弊端。總結如下：

優點

　　1、開發人員可以只關注整個結構中的其中某一層；

　　2、可以很容易的用新的實現來替換原有層次的實現；

　　3、可以降低層與層之間的依賴；

　　4、有利於標準化；

　　5、利於各層邏輯的複用。

缺點

　　1、降低了系統的效能。如果不採用分層式結構，很多業務可以直接造訪資料庫，以此擷取相應的資料，如今卻必須通過中介層來完成。

　　2、有時會導致級聯的修改。這種修改尤其體現在自上而下的方向。如果在展示層中需要增加一個功能，為保證其設計符合分層式結構，可能需要在相應的商務邏輯層和資料訪問層中都增加相應的代碼。

　　3、增加了開發成本。

 

    所以我們所要開發的系統是不是有必要分層值得考慮，如果系統很簡單，不需要分層，那麼就沒必要費很多事寫很多代碼，如果系統很龐大需要合作開發，那麼三層會是最好的選擇。有人很形象地把運用三層結構開發軟體和生產豬肉食品相比擬，並通過把豬從養豬廠被處理的一系列過程最終被賣給消費者說明了三層結構的各個層的作用及它們之間的參考關聯性。見：

    分層的優勢就在於人盡其才，物盡其用，各司其職。試想一下，如果從養豬到宰豬到做成熟食到賣給別人統統由你們一家完成，那麼。。。