DAO和Service層的一些解釋
阿新 • • 發佈：2019-01-29
1，dao和service對應
一般情況下,Hibernate DAO只操作一個POJO物件，因此一個DAO對應一個POJO物件。 Service層是為了處理包含多個POJO物件（即對多個表的資料操作）時，進行事務管理（宣告式事務管理）。Service層（其介面的實現類）被注入多個DAO物件，以完成其資料操作。
2, Service之有無
這一點我的看法未必正確,我的腦海現在有兩種構建業務層的模式:
模式1是Service + DAO,即DAO中只做CRUD及類似的簡單操作(稱之為功能點,不包含業務邏輯),Service中通過呼叫一個或多個
在這種模型中業務邏輯是放在Service中的,事務的邊界也應該在Service中控制. 當然,直接在Service中控制事務會引入非業務邏輯的程式碼,幸好Spring的AOP可以解決這個問題,這也是引入Spring的原因之一.
如果說到缺點,就在於對某些物件的操作就是簡單的CRUD,Service層顯得累贅. 模式2是Service + BO, 而BO = DAO + 業務方法, 在原先DAO的基礎上新增業務方法,形成BO物件。需要注意的是BO中的業務方法往往是針對一個實體物件的，如果需要跨越多個實體物件，則方法應該放在
舉例來說，一個簡單的銀行帳戶管理系統，建立帳戶這個BO物件，裡面可以有修改密碼，取錢等業務方法（不難看出，這些方法都只對單個帳戶物件進行操作）。現在需要新增一個轉賬方法，就應該放在Service中。
這裡Service和BO的關係是什麼樣的呢？再舉一例：以國家行政機關為例：糧食局負責收糧，賣種子等，建設部負責審批土地買賣，建設公路等，這都是行政部分份內的事兒。突然某地發了水災，救災時需要糧食局開倉放糧，建設部修建臨時房屋，如何協調兩個部門？就需要成立專門的救災委員會，由救災委員會出面對兩個部分的資源進行調撥。這裡兩個部分就是BO，而救災委員會就是
模式2的劃分相對複雜，然而可以提高編碼效率。
當然小規模的應用中，沒有Service，完全是DAO或BO也是可以接受的。
3，Service和DAO的介面之有無
介面是一種契約，它可以有多種實現。所以介面之有無取決於具體實現是否需要多樣化。如果鐵定一種DAO或一種Service只有一種實現，那麼抽象出介面的意義不大。然而一些大型應用或許需要DAO和Service的多種實現（比如上面例子中的帳戶DAO，可能需要一種Hibernate實現、一種CMP實現和一種JDO實現），為了向上一層隱藏具體實現類，需要採用介面。
隱藏具體實現類的建立過程，這有兩種方法：一是實用工廠方法，代價是程式碼量大（每個DAO和Service一個工廠）。二是使用Spring的IoC，實現依賴注入，不需要寫額外的程式碼，這也是引入Spring的理由之二。
一般情況下,Hibernate DAO只操作一個POJO物件，因此一個DAO對應一個POJO物件。 Service層是為了處理包含多個POJO物件（即對多個表的資料操作）時，進行事務管理（宣告式事務管理）。Service層（其介面的實現類）被注入多個DAO物件，以完成其資料操作。
2, Service之有無
這一點我的看法未必正確,我的腦海現在有兩種構建業務層的模式:
模式1是Service + DAO,即DAO中只做CRUD及類似的簡單操作(稱之為功能點,不包含業務邏輯),Service中通過呼叫一個或多個
在這種模型中業務邏輯是放在Service中的,事務的邊界也應該在Service中控制. 當然,直接在Service中控制事務會引入非業務邏輯的程式碼,幸好Spring的AOP可以解決這個問題,這也是引入Spring的原因之一.
如果說到缺點,就在於對某些物件的操作就是簡單的CRUD,Service層顯得累贅. 模式2是Service + BO, 而BO = DAO + 業務方法, 在原先DAO的基礎上新增業務方法,形成BO物件。需要注意的是BO中的業務方法往往是針對一個實體物件的，如果需要跨越多個實體物件，則方法應該放在
舉例來說，一個簡單的銀行帳戶管理系統，建立帳戶這個BO物件，裡面可以有修改密碼，取錢等業務方法（不難看出，這些方法都只對單個帳戶物件進行操作）。現在需要新增一個轉賬方法，就應該放在Service中。
這裡Service和BO的關係是什麼樣的呢？再舉一例：以國家行政機關為例：糧食局負責收糧，賣種子等，建設部負責審批土地買賣，建設公路等，這都是行政部分份內的事兒。突然某地發了水災，救災時需要糧食局開倉放糧，建設部修建臨時房屋，如何協調兩個部門？就需要成立專門的救災委員會，由救災委員會出面對兩個部分的資源進行調撥。這裡兩個部分就是BO，而救災委員會就是
模式2的劃分相對複雜，然而可以提高編碼效率。
當然小規模的應用中，沒有Service，完全是DAO或BO也是可以接受的。
3，Service和DAO的介面之有無
介面是一種契約，它可以有多種實現。所以介面之有無取決於具體實現是否需要多樣化。如果鐵定一種DAO或一種Service只有一種實現，那麼抽象出介面的意義不大。然而一些大型應用或許需要DAO和Service的多種實現（比如上面例子中的帳戶DAO，可能需要一種Hibernate實現、一種CMP實現和一種JDO實現），為了向上一層隱藏具體實現類，需要採用介面。
隱藏具體實現類的建立過程，這有兩種方法：一是實用工廠方法，代價是程式碼量大（每個DAO和Service一個工廠）。二是使用Spring的IoC，實現依賴注入，不需要寫額外的程式碼，這也是引入Spring的理由之二。