DAO層：DAO層主要是做資料持久層的工作，負責與資料庫進行聯絡的一些任務都封裝在此，DAO層的設計首先是設計DAO的介面，
然後在Spring的配置檔案中定義此介面的實現類，然後就可在模組中呼叫此介面來進行資料業務的處理，而不用關心此介面的
具體實現類是哪個類，顯得結構非常清晰，DAO層的資料來源配置，以及有關資料庫連線的引數都在Spring的配置檔案中進行配置。


Service層：Service層主要負責業務模組的邏輯應用設計。同樣是首先設計介面，再設計其實現的類，接著再Spring的配置檔案
中配置其實現的關聯。這樣我們就可以在應用中呼叫Service介面來進行業務處理。Service層的業務實現，具體要呼叫到已定義
的DAO層的介面，封裝Service層的業務邏輯有利於通用的業務邏輯的獨立性和重複利用性，程式顯得非常簡潔。



Controller層

:Controller層負責具體的業務模組流程的控制，在此層裡面要呼叫Serice層的介面來控制業務流程，控制的配置
也同樣是在Spring的配置檔案裡面進行，針對具體的業務流程，會有不同的控制器，我們具體的設計過程中可以將流程進行抽象
歸納，設計出可以重複利用的子單元流程模組，這樣不僅使程式結構變得清晰，也大大減少了程式碼量。


View層： 此層與控制層結合比較緊密，需要二者結合起來協同工發。View層主要負責前臺jsp頁面的表示，


DAO層，Service層這兩個層次都可以單獨開發，互相的耦合度很低，完全可以獨立進行，這樣的一種模式在開發大專案的過程中尤
其有優勢，Controller，View層因為耦合度比較高，因而要結合在一起開發，但是也可以看作一個整體獨立於前兩個層進行開發。
這樣，在層與層之前我們只需要知道介面的定義，呼叫介面即可完成所需要的邏輯單元應用，一切顯得非常清晰簡單。

DAO設計的總體規劃需要和設計的表，和實現類之間一一對應。

DAO層所定義的接口裡的方法都大同小異，這是由我們在DAO層對資料庫訪問的操作來決定的，對資料庫的操作，我們基本要用到的
就是新增，更新，刪除，查詢等方法。因而DAO層裡面基本上都應該要涵蓋這些方法對應的操作。除此之外，可以定義一些自定義的
特殊的對資料庫訪問的方法。

Service邏輯層設計


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


 <!--其他方面的補充-->


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


dao完成連線資料庫修改刪除新增等的實現細節，例如sql語句是怎麼寫的，怎麼把物件放入資料庫的。service層是面向功能的，一個
個功能模組比如說銀行登記並完成一次存款，UI要把請求給service層，然後service曾將這一個case分解成許多步驟呼叫底層的實現完
成這次存款，dao就是下面那層。 
dao就是把資料存起來，之所以service的方法會有雷同只不過是因為service得需求不是很複雜不用再service裡面完成太多包裝或者處
理過程可以直接呼叫dao的方法就完成的請求處理例如就要save一個物件，而這個物件是封裝好的，dao裡面有個方法專門save封裝好的
物件於是service的方法就僅僅呼叫一下就o了，函式簽名自然很像了service不能直接接觸持久層，而dao是持久層或者直接訪問持久層
有的時候只是為了分層清楚，為了將來scale up的時候方便我們才把service和dao分開，其實沒必要分開的。 


---------------------------------------------------------------  
根據不同專案的複雜度來確定是否需要分層,如果是小專案的話,2層應該就夠了,分層是為了很好的解耦,和程式的可觀性,還有就
是很好的專案分工,如果遇到某個客戶需要修改某個查詢結果集合,你需要修改的首先是dao的SQL,接著是service的相應呼叫方法來
為VIEW服務,  如果是分層清楚的話,只需要在DAO中加一個方法,在SERVICE中改變起呼叫的方法街口,需要改動的不大,  
-----------------------------------------------------------------  


在用ssh進行開發中，一般情況下都是分為三層:web層spring層dao層，基本的流程是首先定義一個dao介面，然後去實現這個介面，
在定義同類型的service介面（service介面與dao介面是完全一樣），再實現service介面，（這是是用dao介面去注入），然後web層
在去呼叫service層。 
DAO層的職責是純粹的資料操作，如果是hibernate，那就只需要類似getHibernateTemplate().save, update, delete, findyBy*這類
的方法而service層是負責寫業務邏輯的，純粹的業務邏輯，其中的資料操作是通過注入的DAO實現的，但是業務是在這層。 如果你的
service層與dao層程式碼嚴重重複，這說明你的業務比較簡單。複雜業務這個結構的優勢就很明顯了service層的作用是對dao取得的資料
做操作更貼近於業務的實現 dao只是資料的增刪改查，對小型的應用來說，SSH 確實提高了開發成本和開發週期，但是卻有利於擴充套件和
維護。 


利用spring 的ioc 解偶使業務邏輯與持久層鬆偶合。
 -----------------------------------------------------------------  
分層並不一定是絕對的，具體的還是要根據專案實際情況來定，不是麼？如果是理想狀態的話，恐怕在你的service層上面還要再多加一
層的。但是你覺得有必要嗎？ 
實際上，對於小專案來說，直接通過dao來進行操作也不是不可以，搞得太複雜，也沒有必要。這是我的個人感覺。就好像po和dto一樣
，有的人直接就將po傳到web層，有的還要加一個轉換，由dto進行資料傳遞。顯然後者實現更理想，但是你不覺得這樣很麻煩嗎。 微軟的
。net號稱有11層（還是多少層來著，反正層很多），但是實際能分出多少層，還是根據開發者自己情況來定了。要注意程式碼是死的，人
是活的，不要死套框架，否則自己很可能也會陷入開發誤區。 
另外，我們目前設計的一些領域物件，絕大多數都是貧血的。只是一個簡單的javabean，不包含任何邏輯在裡面。怎麼設計才更符合oo
的思想，你也可以參考下domain object方面的討論。這個在javaeye上有很多。