三層架構理論篇

         對于三層架構的理論闡述，我将從三個大的方面去讨論：what、why和how，說白了也就是以三層架構為中心，去了解什麼是三層，為什麼用三層以及怎麼用三層這個三個問題。OK，廢話不多說，進入正題。

         什麼是三層架構？（What）

         通常多層結構的劃分方式有兩種：分别是實體和邏輯。實體上的三層結構是指将整個應用系統分為顯示層、業務層和資料層，并且這三個層面上的實體都是硬體，比如顯示層就是客戶機器，業務層通常是應用程式伺服器，而資料層就是資料庫伺服器了。

         今天我們讨論的主要是邏輯上的三層架構，是在軟體設計時将軟體的業務應用劃分為：表現層（UI）、業務邏輯層（BLL）和資料通路層（DAL）。在軟體體系架構中，分層式結構是最常見、也是最重要的一種結構。下面我們來看看這三層的具體含義和作用是什麼。

         表現層（UserInterface），還有一個概念叫做表示層（User Show Layer），無論叫什麼吧，它們表達的意思基本上是一樣的：一般來講就是指展現給使用者的界面，即使用者在使用一個系統時的所見所得。這層的作用是向使用者展現特定的業務資料，同時采集使用者的輸入資訊和操作，主要表示為Web方式，也可以表示為Winform方式，位于系統的最上層，最接近使用者，為使用者提供了一種互動式操作的界面。

         業務邏輯層（BusinessLogic Layer）：針對具體問題的操作，也可以說是對資料層的操作，對資料業務邏輯進行處理。如果說資料層是各種蔬菜原材料，那麼業務邏輯層就是做菜。同時業務邏輯層也是一座橋梁，負責連接配接UI和DAL，使它們能夠很好的通信，進而完成系統的功能。它的作用有：從DAL中擷取資料，以供UI顯示用；從UI中擷取使用者指令和資料，執行業務邏輯；從UI中擷取使用者指令和資料，通過DAL寫入資料庫中。

         資料通路層（DataAccess Layer）：該層直接跟資料庫打交道，主要操作就是對資料庫進行增添、删除、修改和查找等。需要強調的一點是，資料通路層不是指存儲原始資料的資料庫，而是對資料的一些操作，具體為BLL或者UI提供資料服務。它的作用是：負責對資料庫的通路，可以通路資料庫系統，二進制檔案，文本文檔或者是XML文檔。

         至此我們已經了解了三層架構中每一層的含義和作用，但是僅僅有三層架構并不能讓系統跑起來，因為層與層之間的通信問題是很複雜的，如果單靠參數傳遞進行通信那是非常麻煩的一件事情，是以我們要引入實體層，也就是資料模型，各層都引用資料模型，進而實作各層之間的資料傳遞和通信，說白了實體層就是一個資料結構體，裡面是一些字段屬性。

         說了這麼多，也許大家對三層架構還是沒有一個形象的認識，筆者從網上找了一張不錯的圖，希望可以幫助大家更好的了解三層架構。

         這張圖很好的描述了各層之間的依賴關系，隻是沒有畫出資料庫（DB），那樣的話就很容易讓大家區分資料層和資料通路層這兩個不同的的概念了。

         為什麼使用三層架構？（Why）

         分層的目的是想将複雜問題簡單化，也就是面向對象技術所崇尚的“高内聚，低耦合”。當一個項目過于複雜且涉及資料通路和存儲的問題時，你就要考慮将整個業務應用進行分層，使用三層架構将業務簡化，進而更好的設計和開發應用系統。

         将一個大型項目分層有很多的優勢：首先，開發人員隻需要關注整個系統結構彙總的某一層即可，其他的不需要去考慮，并且這樣可以很容易的實作系統的更新，隻需要用新的實作替換原有層次的實作即可，其他的層次不用動，在後期的維護過程中，極大地降低了維護成本和時間；其次，可以大大的降低層與層之間的依賴，有利于封裝各層的實作，便于各層邏輯的複用；最後，分層也有利于标準化，使系統的結構更加的明确。

         當然，分層也有其自身的缺點：第一，分層降低了系統的性能，本來很多業務可以直接通路資料庫，現在卻要從中間層BLL繞一下，比較麻煩；第二，在某些情況下會導緻連鎖反應，比如你要在UI增加一個功能，為了保證分層結構，就要在相應的BLL和DAL中都加入相應的代碼，麻煩；第三，增加了開發成本，這是顯然的。

         如何使用三層架構？（How）

         三層架構的具體代碼實作的例子，将在下篇博文中重點介紹，本次我們主要讨論在使用三層架構過程中要注意的一些原則或者說是規則。考慮一個項目是不是應該使用三層或者多層設計時，首先考慮是不是真的有必要？如何你的項目邏輯業務簡單，甚至對資料庫通路都沒有，那完全沒必要用三層架構啊。

         即便是說你要使用三層架構，但不是說你把項目分成DAL、BLL和UI三個子產品，就叫三層了，NO！在參考百度百科時，裡面有幾個問題值得思考

        1.      UI裡面隻有少量（或者說沒有）SQL語句或者存儲過程調用，并且你能保證這些語句不會修改資料，越俎代庖？

        2.      如果把你設計的UI拿掉，你的項目還能在Interface或者API的層次上提供所有功能嗎？

        3.      你的DAL可以移植到其他類似的環境的項目中接着運作嗎？

        4.      你所設計的三個子產品，能否部署在不同的伺服器上？

        如果你的答案不都是YES，那麼恭喜你：你的設計還不能算是嚴格意義上的三層結構。因為三層結構的程式需是有一些約定遵守的規則或者說是原則的：

        DAL隻提供基本的資料通路，不包含任何與業務相關的邏輯處理；

        UI隻負責顯示和采集使用者操作，不包含任何的業務相關的邏輯處理；

        BLL負責處理業務邏輯，通過擷取UI傳來的操作指令，決定執行業務邏輯，在需要通路資料庫的時候直接交給DAL處理，處理完成之後，傳回必要的資料給UI。

        還有一點值得注意的是，我們在做設計的時候一定要從BLL出發，而不要從UI出發，所有的業務邏輯都應該在BLL層實作，并且是以面向對象的方式實作。

        至此，相信大家對三層架構有了一個基本的了解，當時要想在實際應用中靈活地去使用三層，還是比較困難的，需要我們不斷的去思考，去實踐，慢慢的摸索才能夠将三層的優勢發揮出來。