典型的三層結構分為表示（presentation）層, 領域（domain）層, 以及基礎架構（infrastructure）層，而微軟的DNA架構定義了三個層：表示層（presentation），業務層（business），和資料儲存層（data access），當然J2ee 也有它不同的分法不過都大同小異吧。既然我用.net做的開發，這大三層我無需多說了,根據我的理解，我對此做了更詳細的分層,介面外觀層、介面規則層、業務介面層、業務邏輯層、實體層、資料訪問層、資料儲存層共七層，其具體的呼叫如圖1所示

（圖1）

由圖1可以看出，雖然我將系統的架構分為七層，實際上大的方面來說，它就是一個典型的三層架構設計思想。單從這個圖來看，資料的呼叫顯得繁瑣而抽象，也許這時候就會有人說，我只是想實現介面上與使用者互動，然後根據使用者的請求將資料讀出/寫入資料庫就好了，為什麼要做如此複雜的分層呼叫呢？從這個問句中我們也只看到了介面和資料庫，也就是說從使用者的需求來說，就是這兩層而已，但是這裡我們首先要搞清楚的是三層架構它主要是為程式設計師為了實現部署、開發、維護企業級資料庫系統而服務的。如果我們在中間層實現了對錶示層和資料庫層的完全脫離，其部署、開發、維護系統的費用和時間至少降低到原來的一半，甚至更多。

系統通過瀏覽器或應用程式客戶端提供與使用者的互動平臺，並向伺服器提交請求（介面外觀層）；使用者提交請求後，介面規則層對使用者的資料按照業務邏輯層要求的介面引數封裝規則封裝使用者資料，然後呼叫業務介面層對外提供的相應命令介面（介面規則層），業務介面層通過對資料進行解析並分別送入不同的邏輯處理並向用戶返回處理結果(業務介面層)；對於資料和命令的不同，處理方式也不同，我們將不同的處理方式都歸類，並將介面層傳入的資料及命令流入對應處理流程（業務規則層）；這時，不同的處理流程分析資料和命令產生出對應的一個實體，這個實體根據其本身的屬性和方法以及上層傳入的命令，將資料處理為資料訪問層需要的介面引數，並向資料訪問層提交訪問資料庫的請求，並向業務介面層返回訪問結果（實體層）；資料訪問層會將資料轉化為資料庫可識別的語句（SQL），並訪問資料庫層，訪問結果會返回給實體層（資料訪問層）；資料庫層處理上層傳入的SQL，讀寫資料庫內建物件，並根據其內建物件本身的關係對資料做進一步校驗和處理（資料庫層）。這裡我所講到的企業級資料庫應用系統，不論它是基於B/S應用系統上的三層架構設計，還是基於C/S應用系統上的三層架構設計，基本上是一樣的，所不同的只是兩種方式常用的資料傳輸協議的不同，B/S應用系統設計一般資料傳遞是通過HTTP來完成的，C/S應用系統設計則更多的是基於TCP/IP協議來傳送資料的，當然，隨著企業級應用系統對安全性方面要求的要求越來越高，更多的防火牆架設於物理線路之間，C/S應用系統的設計也越來越多地趨向於HTTP

常見的三層架構基本包括如下幾個部分，如圖所示。

圖常見的三層架構

l 資料訪問層DAL：用於實現與資料庫的互動和訪問，從資料庫獲取資料或儲存資料到資料庫的部分。

2 業務邏輯層BLL：業務邏輯層承上啟下，用於對上下互動的資料進行邏輯處理，實現業務目標。對於一些複雜的業務邏輯，迴圈演算法  演算法    異常通知 事件通知

Bl  業務邏輯層

迴圈 演算法    異常通知 事件通知

  和表現層有關 的

  和SQL 語句有關的

Da  資料庫訪問 層 

  功能簡單

3 表示層Web：主要實現和使用者的互動，接收使用者請求或返回使用者請求的資料結果的展現，而具體的資料處理則交給業務邏輯層和資料訪問層去處理。功能比較單一，一些複雜的業務邏輯不能寫在表現層，sql語句也不能寫在表示層web裡，如果把、sql語句寫在表示層，會造成錯誤的！

日常開發的很多情況下為了複用一些共同的東西，會把一些各層都用的東西抽象出來。如我們將資料物件實體和方法分離，以便在多個層中傳遞，例如稱為Model。一些共性的通用輔助類和工具方法，如資料校驗、快取處理、加解密處理等，為了讓各個層之間複用，也單獨分離出來，作為獨立的模組使用，例如稱為Common。

此時，所示。