談談service層在mvc架構中的意義和職責

標籤：oracle   基於   意義   通用   web開發   建議   tle   升級   存在   

mvc架構由model，view，controller組成，執行流程一般是：在controller訪問model擷取資料，通過view渲染頁面。

mvc模式是web開發中的基礎模式，採用的是分層設計，各層之間職責分明。然而事與願違，當我們日積月累的基於mvc模式開發之後，會逐漸的感受到層與層之間存在粘連和職責模稜兩可的地方，這就是service層出現的重要原因。

問題是什麼

要提出解決方案，重要的是發現問題的本質。mvc模式在實踐過程中，主要面臨下面幾個難受的問題：

• 在C層直接實現商務邏輯，這將導致：
  • 不同的controller之間，無法共用通用的商務邏輯，比如：折扣計算，反作弊判定，這必然是不合理的。
  • 商務邏輯升級，需直接在原代碼上做修改相容，導致controller代碼不斷膨脹複雜。
  • 遠程服務合約或者調用方式升級，需要找到所有controller裡的調用點，逐一修改。
  • DAO發生替換（比如從oracle遷移mysql），需要找到所有controller裡的調用點，逐一修改。
• 在M層（DAO+model或者ActiveRecord，下面以model泛指）裡實現商務邏輯，這將導致：
  • model承擔了過多的商務邏輯，導致商務邏輯升級需要修改model，然而model的職責並不是業務，這是很矛盾的。
  • 調用1個model中的業務代碼沒有問題，但是遇到跨表事務又該由哪個model管理呢？
  • 商務邏輯實現在model中，如果model發生變更，那麼裡面寫的商務邏輯也得粘貼複製到新的model中，這就是耦合的代價。

我仔細的回想了一下之前的MVC開發模式，上面的問題我幾乎都遇到過並且試圖解決過，比如：

• 為了提升代碼複用，我會把一些通用的功能實現為單獨的工具類（校正登入），並在controller中提供調用。
• 為了給controller提供業務相關的資料，我在ActiveRecord裡實現了業務相關的增刪改查方法供controller調用，更有意思的是：每次表變更欄位，我通過工具gii重建ActiveRecord都會把我實現的方法覆蓋，這就是耦合的代價。

問題的本質是：商務邏輯粘連了C層和M層，應該從C層&M層解耦出來，成為獨立的Service層。由此，在C層可以靈活的替換Service保持高度的簡潔，而M層保持職責單一僅僅為Service提供資料，Service層則實現所有複雜的商務邏輯與通用的商務邏輯。

Service層的職責

根據上面的分析，Service夾在C層和M層中間，從邏輯上大致劃分為3大類：

1. model側的Service：也就是封裝每個model與業務相關的通用資料介面，比如：查詢訂單。（我認為：訪問遠程服務擷取資料也應該歸屬於這一類Service）
2. 中間的Service：封裝通用的商務邏輯，比如：計算訂單折扣（會用到1中的Service）。
3. controller側的Service：基於1、2中的Service進一步封裝對外介面的使用者商務邏輯，當然也不排斥直接存取DAO而不使用上述2個Service（不建議）。

在實踐中，應該會很自然的用到這三類Service，在瞭解了這些概念之後再進行代碼設計，就不會對Service的職責產生困惑了，自然也對MVC有了新的認識。

關於抽象

Controller裡調用"controller側的Service"直接完成業務處理，意味著Controller依賴了具體是哪個Service類。

Service裡調用"DAO/AR"實現資料庫的訪問，意味著Service依賴了具體是拿個"DAO/AR"類。

Service裡調用Service，意味著Service依賴了具體是拿個Service類。

為瞭解除這種耦合，在Web領域一般採用的都是IOC依賴注入來實現"依賴反轉"，JAVA和PHP都可以基於反射實現這個能力，各個mvc架構都有相似的實現。

Service層是否必要呢？

見仁見智，我認為長時間維護的大型項目通過更精細的分層，更加有利於功能的迭代升級。

而對於中小項目，多一層就意味著更多的代碼，而且在設計時還要考慮通用性以及通用性的粒度問題，還不如少動點腦子多寫點冗餘代碼了。

 

更多部落格請直接存取魚兒的部落格

談談service層在mvc架構中的意義和職責