本文轉載於網絡，覺得寫得很透徹。
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上有很多。