Spring的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上有不少。