Service 層設計概念

當我們跟服務生說要一杯咖啡時, 我們只告知服務生說, 大杯, 拿鐵, 不加奶精等, 等待服務生處理好之後, 就拿到一杯咖啡, 而背後這位服務生會做什麼事, 如: 檢查水, 咖啡豆, 需不需要加牛奶, 弄錯了要重弄等等細節. 其實對我們來說就不用太了解了.

而程式的 Service 層, 即是此角色, 其用意在於讓action或daemon呼叫, 主要處理業務邏輯. 也就是Transaction會在service層控制.

至於 action 與 service 的分工, 則有以下原則: action 負責處理網頁資料, 把流程邏輯交由 service 層維護.

如, 頁面資料轉成VO, 應該在action層, 而狀態的轉換或眾行為等業務邏輯應當做在service層. 有幾個好處:

1.service層會是比較接近SD.較好分工.
2.未來要看業務處理邏輯只需要查看service層.
3.某個作業會集中在一兩個service內, 處理流程可以一目了然.
4.action 會比較單純.(處理如重覆提交, check狀態等守門員角色)

需要注意的是, service 層非 DAO 層 (註1). 所以其程式並非簡單的資料存取.
意即, 通常不會看到 insert() update() 這些單純的method.
除非業務邏輯真的這麼簡單. 也意謂著. Service 層目的不是為了共用 (當然若呼叫來源不只網頁, 則可共用, 如WebService或Swing. 以我們系統來說, 很罕見)

註1. DAO層的用意在於提供介面, 將資料存取的方式放在實體物件. 未來有需要更換資料存取方式, 如改成ibatis, JPA, 或甚至不是資料庫, 而是檔案或WebService等. 只需改變實作品, 原本程式都不用調整. 而為了達到此目標, 通常還會有個Factory物件以動態抽換(目前幾乎都交由Spring處理).

DAO層是否需導入, 需看是否未來真有更換 DAO 實作的機會(大部份專案其實更換機率是非常低的), 若機率很低, 只為了未來的可能性, 過度設計, 只會降低開發效率, 得不償失.(要有介面, 實作物件, 新增更改方法參數等都要改兩邊, trace 程式沒辦法直接點進去等).