thinkphp5.0中的service

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有了新的认识。