三層

　　Controller轉換請求引數到模型Bean，跳轉/重定向頁面，響應的處理。
　　Service 完成業務邏輯處理
　　Dao負責所有的DB操作，不管是快取還是持久化儲存。

模型Bean：
　　請求響應Bean                ------->Controller
　　實體Bean                       -------->Service
　　業務處理Bean               --------->Dao 

三者的關係與聯絡：
　　請求響應Bean

簡單的應用，即具備簡單的增刪改查業務，是否需要三層Bean建模？

        針對簡單的應用，如果每層都使用各自Bean進行建模，則Bean之間欄位重複率過高，即使將其共同欄位抽離到抽象Bean中，還是就成了一個業務四個Bean，Bean之間幾乎相同。在層間呼叫，還需要將資料從Controller層的Bean一直傳到Dao的實體Bean，這樣Bean間賦值，感覺程式碼十分冗餘。在業務資料模型在三層中變化很大。

        如果這種場景，把Service層省略掉，瞬間程式碼得到了簡化，Controller和Dao層使用實體Bean，Controller直接透傳實體Bean到Dao層，因為SpringMVC類框架能完成請求欄位到請求介面Bean的直接轉換。這樣，萬一後期，業務發生變化，需要加入額外的邏輯，這樣邏輯就被全部放到了Controller層，以致Controller變大臃腫。這個是最不建議使用的。

        如果這種場景，三層中資料的交換都使用實體Bean，那麼實體Bean的意義就變味了。如果加入了額外的欄位，實體Bean的就徹底的加入了壞味道，從抽象意義上講。但通過的開發者都是這樣做的。
        這就出現了最經典的問題，是用效率和記憶體浪費去換取語義的渾然純粹，還是用語義的不甚純粹來換取效率和記憶體的節省。
        三層都定義Bean模型，則記憶體耗費增三倍左右，開發程式碼冗餘，資料在各層Bean中流轉增加計算開銷。

MVC設計模式與分層設計模式

       MVC設計模式可以說是分層思想的一種實現。分層思想有一個常用的三層設計，ServiceProvider---->Bussines----->DAO。這和MVC很相似，以至於我們很多情況下將他們認為是同一個。

三層架構開發中間件，介面伺服器
        當我們使用三層架構，經典的分層架構，每層都有每層的Model，有些情況下每層的Model很相似，有些情況下每層的Model又大不相同，下層Model的資料來及上層資料或處理產生的資料。從總體上來看，資料是從上層流入到下層，每層都有可能產生運算資料，這些運算資料可能在某些情況下就要傳入到下一層，供下一層使用。

        每一層的設計中，又可以針對不同的問題域，採用分層在此進行設計，每一層暴露出的API中不能包含細節資訊，API需要是乾淨的，純粹的，不能涉及層中的資料模型。