https://blog.csdn.net/u012562943/article/details/53462157

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大類：

model側的Service：也就是封裝每個model與業務相關的通用數據接口，比如：查詢訂單。（我認為：訪問遠程服務獲取數據也應該歸屬於這一類Service）
中間的Service：封裝通用的業務邏輯，比如：計算訂單折扣（會用到1中的Service）。
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框架中的意義和職責