出处：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