• DAO層

主要任務：做資料持久層的工作，負責與資料庫進行聯絡的一些任務都封裝在此。

DAO層的設計：首先是設計DAO層的介面，然後再Spring的配置檔案中定義此介面的實現類，然後就可以在模組中呼叫此介面來進行資料業務的處理，而不用關心此介面的具體實現類是哪一個，顯得結構非常清晰。DAO設計的總體規劃需要和設計的表，和實現類之間一一對應。

DAO層所定義的接口裡的方法，主要是增添改查，以及一些自定義的特殊的對資料庫訪問的方法。

配置：DAO層的資料來源配置，以及有關資料庫連線的引數都在Spring的配置檔案中進行配置。

• Service層

主要任務

Service層的設計：首先設計介面，再設計實現的類，接著在Spring的配置檔案中配置起實現的關聯。

優點：封裝Service層的業務邏輯有利於通用的業務邏輯的獨立性和重複利用性，程式顯得非常簡潔。

這樣我們就可以在應用中呼叫Service介面來進行業務處理。Service層的業務實現，具體要呼叫到已定義的DAO層的介面。   

• Controller層

主要任務：負責具體的業務模組流程的控制，在此層裡要呼叫Service層的介面來控制業務流程。

配置：控制的配置也同樣在Spring的配置檔案中。

具體實現：

• View層 

主要任務：View層與Controller層介面緊密，需要系統開發。View表示層、主要負責前臺JSP頁面的表示。

概述而言：DAO層和Service層可以單獨開發，互相的耦合度很低，可以完全獨立進行，這樣的一種模式在開發大專案中尤其有有事。Controller和View層耦合度較高，因此要結合在一起開發，但是也可以看做一個整體獨立於前兩個層進行開發。這樣，在層與層之間，我們只需要介面的定義，呼叫介面即可完成所需要的邏輯單元應用。

Service層是建立在DAO層之上的，建立了DAO層後才可以建立Service層，而Service層又在Controller層之下的，因而Service層應該既呼叫DAO層的介面，又要提供介面給Controller層的類來進行呼叫，它剛好處於一箇中間層的位置。每個模型都有一個Service介面，每個介面分別封裝各自的業務處理方法。    

在DAO層定義的一些方法，在Service層並沒有使用，那為什麼還要在DAO層進行定義呢？這是由我們定義的需求邏輯所決定的。DAO層的操作 經過抽象後基本上都是通用的，因而我們在定義DAO層的時候可以將相關的方法定義完畢，這樣的好處是在對Service進行擴充套件的時候不需要再對DAO層進行修改，提高了程式的可擴充套件性。   

總結： 
個人理解DAO面向表，Service面向業務。後端開發時先資料庫設計出所有表，然後對每一張表設計出DAO層，然後根據具體的業務邏輯進一步封裝DAO層成一個Service層，對外提供成一個服務。

面向介面程式設計。表示層呼叫控制層，控制層呼叫業務層，業務層呼叫資料訪問層。

Dao層設計與設計的資料庫表，和實現類（對應的Entity或者JavaBean）一一對應。

View層與Controller層結合緊密，需要二者結合協同開發。Service層、Dao層和其他層次耦合很低，完全可以單獨開發。
-------------------------------------------------------------

各層級的呼叫關係

顯示層——控制層——服務層——資料訪問層——持久層——資料層，以ssh為例，

就是顯示層jsp——控制層saction——服務層service——資料訪問層dao——持久層hibernante——資料層mysql

顯示層：人接互動，主要用於資料的展示和資料的錄入

控制層：總指揮，接受使用者提交的請求，根據請求的引數呼叫響應的服務類和需展示的顯示層

服務層：負責業務邏輯處理，過程中需要對資料庫進行操作的話，不親自動手，通過呼叫dao來實現

資料訪問層：顧名思義，就是對資料物件進行增刪改查操作

持久層：負責把資料物件持久化到資料庫

資料層：指資料庫這個層面。