一提到三層架構，很多程序員都能張口就能說出表示層（也有叫UI層、展示層）、業務邏輯層、數據訪問層，但是真正在程序實現和具體的設計的時候並不是死板的就這麼三層。這三層只是在宏觀上分爲這麼三層，其實一個好的架構是有不同層次來構成的，也非絕對的三層。那麼什麼纔是好的架構呢，很多業內人士和專家也給予了具體的解釋和分析，但我想說任何事情沒有一成不變的，架構的設計也是需要具體情況具體對待，不能按部就班，生搬硬套。
首先了解分層的目的和意義在那裏，這是很重要的，也就是說我們爲什麼要分層，有了這個目標，在設計的時候就按照這個目標去設計，只要達到了這個設計的目標，滿足需要，就是一個好的架構。那麼，三層的目的也意義在那裏呢：
第一，對於大型項目來說，分工協作是很重要的，所以考慮到這方面的因素，需要把責任明細化、共同開發，一來這樣可以提高效率，二來也是發揮員工其所長；比如，擅長前端的（jquery、CSS、Html）的員工就關注於表示層，而不用關心具體的數據操作；而擅長梳理業務的人，可以把他們定位在業務層上處理數據流向和輸入輸出。
第二，從面向對象的設計上來講，就是降低偶爾性和依賴性，我不建議業務層直接去New數據訪問層的某一個類來調用，而是應該依賴於接口，而不是一個具體的類，這樣就降低了關注點，這點用到了幾個設計模式，比如工廠模式、依賴注入等，就是爲了實現關注點分離點，使得功能專一的對象封裝起來，對於外界的類不需要關心這個類的具體實現，所以一般都會把這些接口定義爲一層。而且依賴於接口在業務處理上來說，也十分方便，首先定義接口，也就是具體的操作規範，即便沒有具體的實現，各層之間也可以並行開發。
第三，便於維護與擴展，維護修改代碼方便，層次清晰嘛；擴展呢，添加功能方便，也使程序的可讀性提高，但是不要忘了在定義一個類的時候的單一制原則，和開發封閉原則。再舉個例子來講，將來業務發展了，數據量也會增加，可能公司決策有原來的Access數據庫改爲MySql或SqlServer，那麼這應該是數據訪問層的變更，而不應該影響到業務層的變動，應該是把數據庫層依賴於數據接口的實現類的變動。如果業務層調用數據訪問層的時候是依賴的接口，用工廠模式來實現的話，就可以實現這個目的。
所以，在設計架構的時候前期的分析是很重要的。有的人不理解，幹嘛要中間這個業務邏輯層，直接調用數據層不可以嗎？其實我想說沒有什麼是不可以的，只是業務層也有它存在的道理，業務邏輯層，主要負責對數據層的操作，也就是說把一些數據層的操作進行組合。它起到了承上啓下的作用，也是對數據層返回來的數據進行二次加工，舉些例子:我們假設有一段登錄代碼，則可以這樣處理Web程序，表示層負責接收前臺頁面的數據，然後傳給中間層，中間層對數據進行處理，比如格式化，防SQL注入等等一些，這樣的數據再傳給數據訪問層然後與數據庫進行操作，比如與數據庫的用戶名和密碼匹配等等一些代碼。還有就是在實際開發中，很多人直接把DA層的接口拷貝到BLL層，連方法名稱都不改一下。雖然這樣開發快速，但不易於直觀的理解，每一層的方法名稱的定義都應該有他們的意義所在。還有就是其裏面的加工的數據不同，“業務邏輯層”的用途有很多，例如：驗證用戶輸入數據、緩存從數據庫中讀取的數據等等……但是，“中間業務層”的實際目的是將“數據訪問層”的最基礎的存儲邏輯組合起來，形成一種業務規則。
另外，還有一些公共的方法類，比如緩存、對字符串的處理等，這些東西也算在一個輔助層，一般都是寫成靜態類和靜態方法。所以，沒有絕對的三層，只有變通的三層！
爲了彌補自己的不足，特在網上也找了一些資料，補充一下：
所謂三層體系結構，是在客戶端與數據庫之間加入了一箇中間層，也叫組件層。這裏所說的三層體系，不是指物理上的三層，不是簡單地放置三臺機器就是三層體系結構，也不僅僅有B/S應用纔是三層體系結構，三層是指邏輯上的三層，即使這三個層放置到一臺機器上。三層體系的應用程序將業務規則、數據訪問、合法性校驗等工作放到了中間層進行處理。通常情況下，客戶端不直接與數據庫進行交互，而是通過COM/DCOM通訊與中間層建立連接，再經由中間層與數據庫進行交換.開發人員可以將應用的商業邏輯放在中間層應用服務器上，把應用的業務邏輯與用戶界面分開。在保證客戶端功能的前提下，爲用戶提供一個簡潔的界面。這意味着如果需要修改應用程序代碼，只需要對中間層應用服務器進行修改，而不用修改成千上萬的客戶端應用程序。從而使開發人員可以專注於應用系統核心業務邏輯的分析、設計和開發，簡化了應用系統的開發、更新和升級工作。
總的概括爲以下幾點：
優點：
1、開發人員可以只關注整個結構中的其中某一層；
2、可以很容易的用新的實現來替換原有層次的實現；
3、可以降低層與層之間的依賴；
4、有利於標準化；
5、利於各層邏輯的複用。
6、結構更加的明確
7、在後期維護的時候，極大地降低了維護成本和維護時間
缺點
1、降低了系統的性能。這是不言而喻的。如果不採用分層式結構，很多業務可以直接造訪數據庫，以此獲取相應的數據，如今卻必須通過中間層來完成。
2、有時會導致級聯的修改。這種修改尤其體現在自上而下的方向。如果在表示層中需要增加一個功能，爲保證其設計符合分層式結構，可能需要在相應的業務邏輯層和數據訪問層中都增加相應的代碼。
3、增加了開發成本。