一、
前言
最近幾個網友在討論程式設計中的分層設計，反響非常激烈。大家對此非常感興趣，且仁者見仁，智者見智。不管怎麼樣，他們的看法代表了他們對程式的理解，是他們實踐經驗的總結，是寶貴的。今天，這裡我們且不評論他們的見解正確與否,這裡我只談談我對分層的看法.希望能起到拋磚引玉的作用。
二、
三層架構開發簡介
a)
什麼是三層首先，談一下什麼是三層架構，所謂的三層開發就是將整個業務應用劃分為展示層－商務邏輯層―資料訪問層－資料庫等，有的還要細一些，明確地將用戶端的展示層、商務邏輯訪問、和資料訪問及資料庫訪問劃分出來，十分有利於系統的開發，維護、部署和擴充。軟體要分層，其實總結一句話，是為了實現“高內聚、低耦合”。採用“分而治之”的思想，把問題劃分開來各個解決，易於控制，易於延展，易於分配資源。 圖1.三層結構展示層：負責直接跟使用者進行互動，一般也就是指我們的前台，用於資料錄入，資料顯示等。它不應該做太多的工作。表示嘛，也就意味著只做與外觀顯示相關的工作。不屬於他的工作他不用管也不該管。商務邏輯層：用於做一些有效性驗證的工作。以更好的保證程式啟動並執行健壯性。如資料的有效性判斷。不允許為的地方是否輸入了Null 字元串，該輸入Email的，格式是否正確等，資料類型的合法性判斷，該是整型的地方當然不能接受字串了，資料庫操作是否合法，如欄位長度的有效性判斷。sql防注入的問題，使用者的許可權的合法性判斷等，通過以上的諸多判斷以決定是否將操作繼續向後傳遞。盡量保證程式的正常運行資料訪問層：顧名思義，就是用於專門跟資料庫進行互動。對資料的添加，刪除，修改，顯示等。需要強調的是所有的資料對象只在這一層被引用，如System.Data。SqlClient等，除資料層之外的任何地方都不應該出現這樣的應用。ASP.NET可以使用.NET平台快速方便的部署三層架構。ASP.NET革命性的變化是在網頁中也使用基於事件的處理，可以指定處理的後台代碼檔案，可以使用C#,VB,J#作為後台代碼的語言。.NET中可以方便的實現組件的裝配，後台代碼通過命名控制項可以方便的使用自己定義的組件。顯示層放在ASPX頁面中，資料庫操作和邏輯層用組件來實現，這樣就很方便的實現了三層架構。。
b)
為什麼使用三層那麼我們為什麼要使用分層開發呢，它有什麼獨特的優勢呢？.NET開發平台為我們做開發提供了強大的支援人員，使我們的開發變得非常便捷，高效。通過code behind的強大支援，我們可以將頁面設計和代碼設計有效分離，代碼編寫，頁面設計同時進行。這比古老的asp那種插入式編寫要迅速多了，Html歸aspx，代碼歸aspx.cs，看起來倒也蠻清晰的，也沒發現有什麼不妥的地方的確，光從功能實現的基礎來說我們已經做得很好了，尤其對於一個簡單的應用來說，代碼量不是很多的情況下，這種一層結構開發完全夠用了，沒有必要搞得那麼複雜。但是對一個複雜的大型系統來說這樣的設計的缺陷就很嚴重了(下面會具體介紹，分層開發其實也是為大型系統服務的)。在開發過程中我們會不停把代碼到處複製，以實現一些相似的功能。同樣的代碼為什麼要寫那麼多次？不但使程式變得冗長，更不利於維護，一個小小的修改或許會波及很多頁面。稍微不留神就會導致異常的產生。使程式不能正常運行。最主要的物件導向的思想沒有得到絲毫的體現，打著物件導向的幌子卻依然走著面向過程的老路。意識到這樣的問題，我開始將程式中一些公用的處理常式寫成公用方法封裝在類中，供其它程式調用。象一些功能型的代碼集合，資料庫操作，如同SqlHelper那樣對資料操作進行合理封裝，把sql語句，參數列表作為參數，在資料庫操作過程中，只要傳入相應的參數就可以完成特定的資料操作，這就是我一開始的資料訪問層，再不用每次操作資料庫時都寫那些重複性的資料庫作業碼。在新的應用開發中，資料訪問層可以直接拿來用。物件導向的三大特性之一的封裝性在這裡得到了很好的體現。似乎找到了物件導向的感覺，代碼量較以前有了很大的減少，而且修改的時候也比較方便。這下應該可以了吧？試問一下，如果有一天資料庫供應商發生了變化，因為資料量的增加，資料庫有access變成了sql server？這下麻煩大了，原來的資料訪問層失效了，資料操作對象發生了變化，且頁面中涉及資料對象的地方也要進行修改，因為原來可能會使用OleDbDataReader對象將資料傳遞給顯示頁面，現在都得換成SqlDataReader對象，sql和access支援的資料類型也不一致，在顯示資料時進行的資料轉換可能也要進行修改。由sql向access的轉換所做的修改會更多。還有一種情況，因為某種需要，我們要把Web形式的項目改造成windows應用，這時牽涉的修改有多大呢？如果在你的aspx.cs中放了很多處理代碼，或者還有一部分代碼存在於aspx中呢windows應用中可沒有aspx阿，是不是整個系統需要重新來做了？這都是設計不合理惹的禍。再者，就是分布式的情況，現在的設計也無法做到。也就意味著，以上的設計充其量只能算小打小鬧。不知道我的解釋是否讓你體會了到了一些一層開發模式下的缺陷了呢？你是否碰到過這樣的情況呢？幸運的是，多層開發架構的出現很有效解決了這樣的問題。通過將程式架構進行合理的分層，將極大的提高程式的通用性。三層中，各個層之間的分工是很明確的，物件導向嗎，就像一個公司中的部門一樣，每個部門的分工是不一樣的，是哪個部門的任務就有哪個部門完成，對應的，各個部門的維護工作也有各自完成且不會影響其它的部門，至少影響不是很大，否則就只能說明分層還不合理。各個層之間通過有效協作來完成系統的高效運行。展示層就是用來做接受/顯示資料的工作，它要通過與其它層的協作來完成使用者的請求，在這一層不該放太多的代碼。邏輯層就是用來做資料有效性判斷的，前面已經說過了，資料層就是用來完成底層資料互動的。展示層就不該去實現邏輯層的功能，當然我們會在用戶端對使用者的輸入做一些判斷，但伺服器端，驗證還要做。使用者完全可以繞過用戶端驗證不是嗎？現在我們在看上面說的問題，資料庫發生了改變，我們只需要修改資料訪問層，其它的地方我們都不用去管，這裡我傾向於藉助自訂資料實體來負責層與層之間的資料互動，我們把資料填充到自訂實體中，使用自訂實體的好處請參考我上面的兩篇關於自訂實體的介紹的文章。通過資料訪問層來完全封裝資料供應商，使資料訪問層對其它層完全透明，這樣將資料庫改變帶來的修改完全限定在資料訪問層內。我們可以藉助一些模式來設計一個通用的資料訪問層，這樣即使資料庫發生改變，我們只要修改一下配置就可以輕鬆搞定。對於開發平台的改變也變得很容易，不管是windows還是web，變化的只是介面而已，也就是所謂的展示層，它的核心沒有變，相當於我們重作一個殼。展示層的代碼是很少的，所以修改是很有限的，其它兩層也不要修改就可以迅速做到web程式向windows程式的過渡。你體會到三層的優勢了嗎？當然多層設計還有很多優秀的地方，我只是介紹了其中的一小部分。下面引入我所理解的三層的概念。
c)
我的三層結構。那麼怎麼才能寫出一個比較好的三層結構呢？下面說說我在程式設計中採用的做法，當然這裡談的只是我對三層的理解，不一定準確。歡迎拍磚。呵呵 程式設計追求的是代碼的通用性，可移植性，可維護性、功能擴充。怎麼才能做到這些呢？這需要我們大量的實踐經驗做支撐。對物件導向思想的深入瞭解才能做到。個人覺得優秀的多層結構的設計肯定要先精通模式設計，不過遺憾的是對模式設計研究好長一段時間，依然沒能領略到它的精髓，研究模式設計真的很過癮哦。以上是我在層序設計中所使用的分層。
Web
層：也就是展示層，它負責響應使用者的請求，對於這一層越薄越好，一般不應該寫太多代碼，或者為了頁面顯示的需要做少量的代碼。大量的處理工作都交給其它的層去完成。就好比傳遞員，只負責接受，並將請求向後傳遞，具體怎麼做它不用管。
Common
層：這裡用來封裝一些常用的功能性代碼，主要用來為其它層服務的。還有存放一些自訂實體類型和自訂實體類型集合。用於各層次之間資料互動的載體。如User，UserCollection，關於自訂實體這裡就不展開了，如果系統複雜的話這一層應該比較厚實，包括下面的BLL層也是如此。
BLL
層：就是邏輯層，用來對資料進行有效性驗證，牽涉到對敏感性資料的操作都需要經過這裡做判斷，然後才能決定操作是否合法。
Dal
層：資料訪問層；封裝對資料庫的操作。我們可以做一個通用的資料訪問層，下次開發的時候，就可以直接拿過來用。很爽的。有一點從這裡傳進來、傳出去的資料都用自訂實體代替，這樣就可以實現資料訪問層對其它層的完全透明。這裡封裝所有於資料庫相關的代碼，包括sql語句，預存程序等。分層的思路說完了，在多人開發系統的過程中，就可以按層來劃分任務，只要設計的時候把介面定義好，開發人員就可以同時開發。而且不會發生衝突，做前台的人根本就不需要知道資料庫結構是什麼，該怎麼去尋找，更新，刪除資料，他直觀調用響應的方法就可以了。資料訪問層的人也不需要知道前台發生了什麼，定義好與其它層互動的介面，規定好參數就行。各個層都一樣，做好自己的工作就可以了，只要能做到對其它層的完全透明。這樣就可以將修改限定在一個比較小的範圍內。但各個層具體的代碼該怎麼組織，我想這就要看個人的造詣了，要開發出高效能，可擴充的代碼就需要結合模式設計的思想，通過代碼結構的科學、合理的設計方能在日後的維護過程中遊刃有餘。
三、
總結
1) 從開發角度和應用角度來看，三層架構比雙層或單層結構都有更大的優勢。三層結構適合群體開發，每人可以有不同的分工，協同工作使效率倍增。開發雙層或單層應用時，每個開發人員都應對系統有較深的理解，能力要求很高，開發三層應用時，則可以結合多方面的人才，只需少數人對系統全面瞭解，從一定程度工降低了開發的難度
2) 三層架構可以更好的支援分散式運算環境。邏輯層的應用程式可以有多個機器上運行，充分利用網路的計算功能。分散式運算的潛力巨大，遠比升級CPU有效。美國人曾利用分式計算解密，幾個月就破解了據稱永遠都破不了的密碼
3) 也是三層架構的最大優點是它的安全性。使用者端只能通過邏輯層來訪問資料層，減少了進入點，把很多危險的系統功能都屏蔽了
