層次不是越多越好的，而是視乎項目的實際需要，這一點要明確；
常用的3層結構就是：數據訪問層、業務邏輯層、UI層
而項目可能有更多的需要，
例如一個項目用了Web Service，那麼業務邏輯層和UI層之間就會多了一層；
如果用的是Remoting，那麼業務邏輯層與UI層之間就有Remoting代理和Remoting服務兩層；
如果項目比較大，複雜度很高，那麼業務邏輯層內部如果缺乏規劃也會變得混亂，那麼視乎實際的需要就會把它劃分爲2~3層；如果項目併發量很大，需要分佈式技術，那麼層次又要加......
個人認爲，在把項目架構理解的比較透徹之前，迷信所謂的n層結構其實意義不大----而僅僅能夠作爲參考
尤其是在.net平臺下
------------------------------------------------------------------------------
數據庫，數據訪問層，實體和數據轉換存儲層，業務邏輯層（facade），純實體層，web層，6層夠用了，實在不行，再加事務處理，驗證處理層等等。。。
------------------------------------------------------------------------------
表示層-代理層-外觀層-業務規則層-數據訪問層-實體層-數據庫
------------------------------------------------------------------------------
一般的，信息系統有七成結構：
1、用戶層：用戶面向對象操作
2、業務層：信息系統業務模型
3、功能層：信息系統功能模型
4、數據層：信息系統數據模型
5、工具層：信息系統開發工具
6、OS層： 網絡操作系統
7、物理層：網絡與通信硬件
一般而言,用戶在第1、2層上工作,程序員在第3層上工作,信息系統分析員在第4層上工作,DBA與系統管理員在第5、6層上工作,硬件安裝與維護人員在第7層上工作。上述七層的相互關係是:下一層是上一層的基礎,上一層是下一層的實現目標。由上向下是系統分析的過程,而由下向上是系統實現的過程。
------------------------------------------------------------------------------
所謂七層指的是：
1。業務外觀
2。業務規則
3。數據訪問
4。系統框架
5。Web服務
6。Web界面
7。Windows界面
等七個層面，個人認爲，不同的項目依據各自的特點只要對相應的層面進行裁減，就能得出符合各個項目的特點的系統組織框架。
比如：
含有以上各個層面的爲分佈式應用系統的，
含有業務外觀，業務規則，數據訪問，系統框架，Web服務爲Web服務器
含有業務外觀，業務規則，數據訪問，系統框架，Windows界面爲桌面應用系統。
關鍵是要適當的剪裁
------------------------------------------------------------------------------
微軟這個七層架構害了很多人啊。
其實不管七層還是三層，其基本思想是一致的，就是界面和業務邏輯分開，業務邏輯和數據訪問分開。
外觀層是幹什麼的呢，我理解就是你在做一個業務的時候，可能要與很多個業務邏輯層的對象打交道，這樣如果需要的類很多的話就有點凌亂，而“外觀”指的是什麼的外觀呢？就是某個業務（或某些相關業務）的外界能看到的面貌，我並不關心你用了多少類來實現這個業務，我只想通過這個窗口實現我的業務。就像現在的政務大廳，我去辦事的時候把文件交到一個窗口，具體裏面是怎麼操作，都是誰來操作我並不關心，到時間取結果就是了。而沒有外觀模式的話我是不是就得拿着文件到處找人，到處蓋章了。