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框架都有相似的實現。