一、前言
二、三層架構開發簡介
a) 什麼是三層
首先，談一下什麼是三層架構，所謂的三層開發就是將整個業務應用劃分為表示層－業務邏輯層―資料訪問層－資料庫等，有的還要細一些，明確地將客戶端的表示層、業務邏輯訪問、和資料訪問及資料庫訪問劃分出來，十分有利於系統的開發，維護、部署和擴充套件。
軟體要分層，其實總結一句話，是為了實現「高內聚、低耦合」。採用「分而治之」的思想，把問題劃分開來各個解決，易於控制，易於延展，易於分配資源。
圖1.三層結構示意圖
表示層：負責直接跟使用者進行互動，一般也就是指我們的前台，用於資料錄入，資料顯示等。它不應該做太多的工作。表示嘛，也就意味著只做與外觀顯示相關的工作。不屬於他的工作他不用管也不該管。
業務邏輯層：用於做一些有效性驗證的工作。以更好的保證程式執行的健壯性。如資料的有效性判斷。不允許為的地方是否輸入了空字串，該輸入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)也是三層架構的最大優點是它的安全性。使用者端只能通過邏輯層來訪問資料層，減少了入口點，把很多危險的系統功能都遮蔽了
談談三層結構開發的理解
一 前言 二 三層架構開發簡介 a 什麼是三層 首先，談一下什麼是三層架構，所謂的三層開發就是將整個業務應用劃分為表示層 業務邏輯層 資料訪問層 資料庫等，有的還要細一些，明確地將客戶端的表示層 業務邏輯訪問 和資料訪問及資料庫訪問劃分出來，十分有利於系統的開發，維護 部署和擴充套件。軟體要分層，其...
三層 我眼中的三層結構
從行為型模式命令模式引發的對三層的思考。記得 大話設計模式 中對命令模式的講解。燒烤攤和燒烤店之間的區別。由於客戶和烤羊肉串老闆的 緊耦合 所以容易出錯，容易混亂，也容易挑剔。這其實就是 行為請求者 與 行為實現者 的緊耦合。對請求排隊或記錄請求日誌，以及支援可撤銷的操作等行為時，行為請求者 與 行...
三層架構理解
檢視文章 三層架構 2008 06 12 15 30 三層架構是 資料層，業務層，表示層。資料層從資料庫中取出 10。業務層按照一定的邏輯 這裡我們舉例取溫度的邏輯 翻譯成 10攝氏度。表示層顯現給使用者 哎呀，今天好冷！層就相當於乙個黑盒子，我們不用知道它內部怎麼實現，只需要知道如何去呼叫它就行了...