所謂的三層開發就是將系統的整個業務應用劃分為展示層——商務邏輯層——資料訪問層，這樣有利於系統的開發、維護、部署和擴充。

1．什麼是三層架構     所謂的三層開發就是將系統的整個業務應用劃分為展示層——商務邏輯層——資料訪問層，這樣有利於系統的開發、維護、部署和擴充。    分層是為了實現“高內聚、低耦合”。採用“分而治之”的思想，把問題劃分開來各個解決，易於控制，易於延展，易於分配資源。         展示層：負責直接跟使用者進行互動，一般也就是指系統的介面，用於資料錄入，資料顯示等。意味著只做與外觀顯示相關的工作，不屬於他的工作不用做。    商務邏輯層：用於做一些有效性驗證的工作，以更好地保證程式啟動並執行健壯性。如完成資料添加、修改和查詢業務等；不允許指定的文字框中輸入Null 字元串，資料格式是否正確及資料類型驗證；使用者的許可權的合法性判斷等等，通過以上的諸多判斷以決定是否將操作繼續向後傳遞，盡量保證程式的正常運行。    資料訪問層：顧名思義，就是用於專門跟資料庫進行互動。執行資料的添加、刪除、修改和顯示等。需要強調的是，所有的資料對象只在這一層被引用，如System.Data.SqlClient等，除資料層之外的任何地方都不應該出現這樣的引用。     ASP.NET可以使用.NET平台快速方便地部署三層架構。ASP.NET革命性的變化是在網頁中也使用基於事件的處理，可以指定處理的後台代碼檔案，可以使用C#、VB、C++和J#作為後台代碼的語言。. NET中可以方便的實現組件的裝配，後台代碼通過命名空間可以方便的使用自己定義的組件。顯示層放在ASPX頁面中，資料庫操作和邏輯層用組件或封裝類來實現，這樣就很方便的實現了三層架構。 2．為什麼使用三層架構     對於一個簡單的應用程式來說，代碼量不是很多的情況下，一層結構或二層結構開發完全夠用，沒有必要將其複雜化，如果對一個複雜的大型系統，設計為一層結構或二層結構開發，那麼這樣的設計存在很嚴重缺陷。下面會具體介紹，分層開發其實是為大型系統服務的。    在開發過程中，初級程式人員出現相似的功能經常複製代碼，那麼同樣的代碼為什麼要寫那麼多次？不但使程式變得冗長，更不利於維護，一個小小的修改或許會涉及很多頁面，經常導致異常的產生使程式不能正常運行。最主要的物件導向的思想沒有得到絲毫的體現，打著物件導向的幌子卻依然走著面向過程的道路。    意識到這樣的問題，初級程式人員開始將程式中一些公用的處理常式寫成公用方法，封裝在類中，供其它程式調用。例如寫一個資料操作類，對資料操作進行合理封裝，在資料庫操作過程中，只要類中的相應方法（資料添加、修改、查詢等）可以完成特定的資料操作，這就是資料訪問層，不用每次操作資料庫時都寫那些重複性的資料庫作業碼。在新的應用開發中，資料訪問層可以直接拿來用。物件導向的三大特性之一的封裝性在這裡得到了很好的體現。讀者現在似乎找到了物件導向的感覺，代碼量較以前有了很大的減少，而且修改的時候也比較方便，也實現了代碼的重用性。 下面舉兩個案例，解釋一下為什麼要使用三層架構。 案例一： 資料庫系統軟體由於資料量的不斷增加，資料庫由Access變成了SQL Server資料庫，這樣原來的資料訪問層失效了，資料操作對象發生了變化，並且頁面中涉及資料對象的地方也要進行修改，因為原來可能會使用OleDbDataReader對象將資料傳遞給顯示頁面，現在都得換成SqlDataReader對象，SQL Server和Access支援的資料類型也不一致，在顯示資料時進行的資料轉換也要進行修改，這是其中一種情況。 案例二： 由於特殊情況需要，把Web形式的項目改造成Windows應用，此時需要做多少修改呢？如果在Aspx.cs中佔據了大量代碼，或者還有部分代碼存在於Aspx中，那麼整個系統是否需要重新來開發呢？      在上面的案例中是否體會到了沒有分層開發模式的缺陷呢？是否碰到過這樣的情況呢？這都是由設計不合理造成的，多層開發架構的出現可以很好地解決該問題，通過程式架構進行合理的分層，將極大地提高程式的通用性。 3．使用三層架構開發的優點 使用三層架構開發有以下優點：    從開發角度和應用角度來看，三層架構比二層架構或單層架構都有更大的優勢。三層架構適合團隊開發，每人可以有不同的分工，協同工作使效率倍增。開發二層或單層應用程式時，每個開發人員都應對系統有較深的理解，能力要求很高，開發三層應用程式時，則可以結合多方面的人才，只需少數人對系統全面瞭解即可，從一定程度降低了開發的難度。    三層架構可以更好的支援分散式運算環境。邏輯層的應用程式可以在多個電腦上運行，充分利用網路的計算功能。分散式運算的潛力巨大，遠比升級CPU有效。美國人曾利用分式計算解密，幾個月就破解了據稱永遠都破解不了的密碼。    三層架構的最大優點是它的安全性。使用者只能通過邏輯層來訪問資料層，減少了進入點，把很多危險的系統功能都屏蔽了。 4．三層架構的種類 目前，團隊開發人員在開發項目時，大多都使用分層開發架構設計，最常見的就是三層架構，目的在於使各個層之間只能夠被它相鄰的層產生影響，但是這個限制常常在使用多層開發的時候被違反，這對系統的開發是有害的。三層架構按驅動模式可劃分三種：資料層驅動模式、陳述層驅動模式和隔離驅動模式，其中隔離驅動模式開發最為重要。下面通過三種模式的對比，介紹隔離驅動模式的重要性。      資料層驅動模式    所謂的資料層驅動模式，就是先設計資料層，陳述層圍繞資料層展開，一旦完成了資料層和陳述層，業務層就圍繞資料層展開。因為陳述層是圍繞資料層展開的，這將會使陳述層中的約束不準確，並且限制了業務層的變更。由於業務層受到限制，一些簡單變化可以通過SQL查詢和預存程序來實現。    這種模式非常的普遍，它和傳統的客戶服務端開發相似，並且是圍繞已經存在的資料庫設計的。由於陳述層是圍繞資料層設計的，它常常是憑直覺模仿資料層的實際結構。      常常存在一種額外的反饋迴圈在陳述層到資料之間，當在設計陳述層不容易實現的時候常常會去修改資料層，也就形成了這種反饋迴圈。開發人員請求修改資料庫方便陳述層的開發，但是對資料層的設計卻是有害的。這種改變是人為的而沒考慮到其他需求的限制。這種修改經常會違反至少損害資料的特有規則，導致不必要的資料冗餘和資料的非標準化。     陳述層驅動模式    陳述層驅動模式是資料層圍繞陳述層展開的。業務層的完成一般是通過簡單的SQL查詢和很少的變化或者隔離。由於資料庫的設計是為了陳述層的方便，並非從資料層設計方面考慮，所以資料庫的設計在效能上通常很低。陳述層驅動模式設計圖1.6所示。      隔離驅動模式     用隔離驅動模式設計，陳述層和資料層被獨立的開發，常常是平行開發。這兩層在設計時沒有任何的相互幹擾，所以不會存在人為的約束和有害的設計項目。當兩層都設計完成後，再設計業務層。業務層的責任就是在沒有對資料層和陳述層的需求變化的基礎上完成所有的轉換。陳述層驅動模式設計。       因為現在陳述層和資料層是完全獨立的，當業務層需求改變的時候，陳述層和資料層都可以做相應的修改而不影響對方。改變兩個在物理上不相鄰的層不會直接對其他層產生影響或發生衝突。這就允許資料層結構的調整或者陳述層根據使用者的需求做相應的變化，而不需要系統做大的調整或者修改。表1.1將對這3種驅動模式進行對比。 表  種驅動模式對比    資料層驅動模式 陳述層驅動模式 隔離驅動模式 資料庫 （1）很容易設計 （2）產生負面影響 （3）很難改變資料層，因為它和陳述層緊密綁定 （1）資料庫設計很糟 （2）嚴重的不正常化設計 （3）其他系統不易使用 （4）很難改變資料層，由於它跟陳述層緊密綁定 （1）最佳化設計 （2）集中設計資料庫，陳述層對它影響很小 業務需求 常常不能適應業務需求變化 常常適應業務需求變化 適應需求變化 使用者介面 是圍繞資料層而不是圍繞使用者，不易修改 適合使用者擴充介面 適合使用者擴充介面 擴充性 通常可擴張，但是常常在使用者介面需要比較多的重寫以滿足資料庫的結構，同時資料庫可能需要儲存一些冗餘的欄位 完整性的擴張很難，常常只有通過“剪下，粘貼”函數來實現 很容易擴充      綜上所述，很容易看出隔離驅動模式的優點，隔離驅動模式設計可以極大地提高程式的擴充性。在1.3.2節中的應用中就採用了三層架構的隔離驅動模式。