三層究竟如何？

近日看到了一篇關于反三層的文章，手也癢癢了，就犧牲些時間，拿出來把這個老得掉牙的話題拿出重談。

1. 什么是三層

很多人愛把三層架構和MVC混為一談，但是我們可以從最簡單的角度去考慮他們的不同：

在設計模式中一般都會有這樣一章，MVC設計模式，而從沒見過哪本書中有寫過三層架構設計模式。

回歸三層，三層一般來講分為兩類：

A. 物理上的三層架構

B. 邏輯上的三層架構

現在就逐個談起，來看下究竟三層是否要走開。

2. 邏輯三層架構

邏輯三層架構從概念上看很容易，用戶界面層，業務邏輯層，數據訪問層。每一層都有自己所專有的職責。

三層架構是一切企業級架構的核心，直至Petshop中的七層，或者是一般企業中的五層都是以三層做為一個中心，在這里，我們可以說N=3。

用戶界面層專職顯示工作，與用戶直接打交道。

業務邏輯層用于做一些復雜的業務處理。

數據訪問層用于與數據庫做一個交互，做常規的增刪改查的操作。

這些很簡單，點到為止。

3. 物理三層架構

物理三層架構是以邏輯的三層架構為基礎的。如果沒有了邏輯的三層，就根本談不上物理三層架構的部署。

什么是物理三層架構？

從簡單了說就是每一層都分別做成一個組件，如業務邏輯組件，業務實體組件，數據訪問組件等。

再到麻煩了一些就是構建分布式系統，例如將業務邏輯層與數據訪問分別部署再不同的服務器上。

4. 再論存儲過程

存儲過程作為一個SQLAS，與每門語言一樣，也有著自己的優點和缺點。

來與數據庫打交道無非三個方法：

A. 在程序邏輯中書寫SQL語句，其中包含SQL字符串拼接最為常見

B. 在數據訪問層使用ORM框架，在.NET項目中以LINQ TO SQL和NHibernate為主。（其實兩者在實際項目中都不常用）

C. 使用存儲過程

我們來分析一下他們之間的優缺點：

在程序邏輯中寫SQL語句是很難處理復雜業務邏輯的，困難的引號匹配，復雜的字符串拼接過程，以及字符串拼接過程中的效率損失是我們不得不考慮的。

ORM框架是一個好辦法，這個我不報什么懷疑意見，但是LINQ TO SQL略顯蹩腳的語法，讓常規程序員在C#和LINQ之間來回轉換不是件容易事。NHibernate就不說了，這個在中國大多數公司來說還算是個非主流框架，而且與VS的集成不是很令人滿意。

于是，處理復雜邏輯，如復雜的事務處理時，存儲過程幾乎成了唯一的方法。

但是，存儲過程一樣有著他的致命缺點，就是他的移植性很差，

A. 當我們的項目更換數據庫時，我們就要把存儲過程完整地去拷貝到另外一個數據庫，然后考慮他們的兼容問題。

B. 當我們修改數據層訪問代碼時，我們需要動的不再是應用程序服務器的代碼，而是數據庫端的代碼，這是稍顯痛苦的地方 。

5. 三層的優點

現在有人去質疑三層，讓三層走開，問題不在于三層。而在于他錯用了三層。好刀要用在刃上，否則，恐怕只會弄巧成拙。

那么下面就說三層的優點究竟在哪？

A. 正如上面而言，邏輯上的三層是物理上三層的前提條件。

B. 三層可以讓團隊開發中，每個成員有著自己的關注點，而且利于小組成員的分工。

C. 重用數據訪問層和業務邏輯層

D. 多語言協作（如數據訪問層用vb,業務邏輯層用C#，情況很少見）

E. 一定程序上的易維護，但我個人認為這點體現的不明顯，就像那位兄弟講的那樣，如果修改一個字段，需要在三層都進行修改。

6. 三層不三層

究竟是三層還是不三層，這一直是困擾很多人的問題。

正如每一種設計模式一樣，這些都是一把雙刃劍，用得好了會讓你很方便，但是用錯了卻是適得其反。

是否三層，要縱觀整個項目，然后去提前挖掘他的潛在變化點，然后再去想，如果這個項目用了三層對你有什么好處。

如果你想不到，那么就不要去三層。

常用三層的情況如下：

A. 產品型公司需要向上屏蔽底層細節，因此需要封裝好很多訪問以及業務邏輯，這個時候必須三層。

B. 項目很大，需要多成員合作，讓一個成員既關注頂層的業務邏輯，又要關注頁面美觀，還要去注意數據訪問的效率，這是不現實的。

C. 項目巨大，需要應用程序邏輯分布式。

7. 三層之擴展

在我所有的文章中，都在強調思想的重要性，我不喜歡被前人去限制住自己的思路，不喜歡輕易相信書上的觀點，除非被我證實過。本篇也是一樣。

究竟是三層，我覺得三層本就是一個思想，沒必要說這樣就是三層，那樣就不是三層，這就把知識學的太死了。

還記得國外哪位大師給AJAX下的定義：只要能夠提高用戶體驗的技術，我們就將之統稱為AJAX。

其實，我個人認為三層也是一樣：能夠讓我們的項目適應變化，可重用，方便程序員的架構方法，我們就可以稱之為三層。

8. 擴展三層分類

A. 簡化版三層：

當業務邏輯簡單時，就把業務邏輯層簡化，于是就形成了這樣的結構：

.aspx為用戶界面層 .aspx.cs為業務邏輯層 .cs單獨搭建數據訪問層

B. 一些變化

通常的公司都會有自己數據訪問類，就像Petshop中的SqlHelper。我們也可以把這單獨叫成一層，不過這都是概念問題了。

C. 分出業務邏輯和業務實體

對于很多項目來說，業務邏輯處理都是相對復雜的，說個簡單的，比如在登陸界面，當傳出密碼到存入數據庫，就需要一個加密的過程，我們就可以把這個過程封裝到業務邏輯層內。另外，比如一些復雜的流程處理，我們同樣可以在業務邏輯層去。

業務實體就不說了，這個很常見。

D. 無業務實體

在很多辦公OA的項目中，數據往往是無實體的，因為用戶可以根據自己的選擇去動態地構建數據庫表字段，因此這個時候，業務實體就沒有存在的必要了。

E.  極端簡化

在很多小項目中，業務流程簡單，數據處理容易，更沒有一些復雜的操作，沒有團隊合作，那么我們就沒有必要去分層。這個時候的分層只會讓我們的編碼量以及維護量更大。那么這種情況算什么？

我之前提過這個概念，只要能夠讓我們的項目適應變化，可重用，方便程序員的開發，我就把他叫做三層，那么這么來說，這種最簡單的方式其實我們也能把他勉強叫成是“三層”吧。

9 . 總結

三層不三層，三層要怎么三層，這本來就是一個很難去抉擇的問題。

所以，我還是那個觀點，適應變化的架構方式就是最好的方式。