出處：https://blog.csdn.net/weixin_43215482/article/details/87932734
1、service層出現的契機：
mvc框架由model，view，controller組成，執行流程一般是：在controller訪問model獲取數據，通過view渲染頁面。
mvc模式是web開發中的基礎模式，采用的是分層設計，各層之間職責分明。然而事與願違，當我們日積月累的基於mvc模式開發之后，會逐漸的感受到層與層之間存在粘連和職責模棱兩可的地方，這就是service層出現的重要原因。
2、mvc模式在實踐過程中，主要面臨下面幾個難受的問題：
-
在C層直接實現業務邏輯，這將導致：
-
-不同的controller之間，無法共享通用的業務邏輯，比如：折扣計算，反作弊判定，這必然是不合理的。
-
-業務邏輯升級，需直接在原代碼上做修改兼容，導致controller代碼不斷膨脹復雜。
-
-遠程服務協議或者調用方式升級，需要找到所有controller里的調用點，逐一修改。
-
-DAO發生替換（比如從oracle遷移mysql），需要找到所有controller里的調用點，逐一修改。
-
-
在M層（DAO+model或者ActiveRecord，下面以model泛指）里實現業務邏輯，這將導致：
-
-model承擔了過多的業務邏輯，導致業務邏輯升級需要修改model，然而model的職責並不是業務，這是很矛盾的。
-
-調用1個model中的業務代碼沒有問題，但是遇到跨表事務又該由哪個model管理呢？
-
-業務邏輯實現在model中，如果model發生變更，那么里面寫的業務邏輯也得粘貼復制到新的model中，這就是耦合的代價。
-
-
問題的本質是：業務邏輯粘連了C層和M層，應該從C層&M層解耦出來，成為獨立的Service層。由此，在C層可以靈活的替換Service保持高度的簡潔，而M層保持職責單一僅僅為Service提供數據，Service層則實現所有復雜的業務邏輯與通用的業務邏輯。
3、Service層的職責：
根據上面的分析，Service夾在C層和M層中間，從邏輯上大致划分為3大類：
- model側的Service：也就是封裝每個model與業務相關的通用數據接口，比如：查詢訂單。（我認為：訪問遠程服務獲取數據也應該歸屬於這一類Service）
- 中間的Service：封裝通用的業務邏輯，比如：計算訂單折扣（會用到1中的Service）。
- controller側的Service：基於1、2中的Service進一步封裝對外接口的用戶業務邏輯，當然也不排斥直接訪問DAO而不使用上述2個Service（不建議）。
在實踐中，應該會很自然的用到這三類Service，在了解了這些概念之后再進行代碼設計，就不會對Service的職責產生困惑了，自然也對MVC有了新的認識。
4、抽象：
Controller里調用"controller側的Service"直接完成業務處理，意味着Controller依賴了具體是哪個Service類。
Service里調用"DAO/AR"實現數據庫的訪問，意味着Service依賴了具體是拿個"DAO/AR"類。
Service里調用Service，意味着Service依賴了具體是拿個Service類。
為了解除這種耦合，在Web領域一般采用的都是IOC依賴注入來實現"依賴反轉"，JAVA和PHP都可以基於反射實現這個能力，各個mvc框架都有相似的實現。
其它參考：
https://www.cnblogs.com/youmingkuang/p/11963404.html
https://www.cnblogs.com/laowenBlog/p/12937429.html