laravel里面要用msvc模式的疑惑点

Question

laravel里面要用msvc模式的话，有几个问题：

1. 控制器要不要直接使用model？
   疑惑点：如果不的话，Users::count()这种查询也在Service里面封装的话会不会算是过度封装？但是使用的话感觉又会打乱代码层次结构
2. 在控制器中使用service或者在service中使用model，是要通过依赖注入使用还是直接use?
   疑惑点：注入的话，可能有的注入的对象使用频率会很低，直接use的话又感觉怪怪的
3. 以上是主要疑惑点，希望大佬能再指出一些其他需要注意的点，感激不尽

Answer 1

其实如果用service层的话，是将主要逻辑放在service层，但是service层并不是model层的代理。model一般做数据映射关系，以及数据属性的处理操作。

可以这么理解，model层是操作当前model对象的所有方法集。是对象方法，只针对当前数据映射的对象。比如你要把当前文章对应的文章对象，生成一个摘要内容。只是针对单个文章对象操作。
service层的话，则会比较多。有控制器处理代理功能。根据条件查询特定的文章功能。比如统计站点所有文章数据，就类似你说的Users::count()。

service中使用model可以用注入方式。注入的方式后期变更其实主要是“调用方”变更，而不是"服务方"变更。当然，如果你的service本身就是针对某个特定对象的，则直接使用use的方式也可以。看业务需求变更程度。注入的方式后期变更会灵活一些

Answer 2

先要明白，为什么我们都在谈分层。

在以前没有 Service 时，如果要查询一个 id 为 1 切 status 为 1 的数据，而且这段代码需要重复用到，那么很多人的第一想法是定义一个方法到 Model 里面去。因为在业务中，我们会遇到很多这种事情，然后随着更新 Model 就会越来越大，大到难以维护，所以我们就需要把 Model 拆分。常规的拆分除了 Service 还有 Repository ，这两种组合加上去。因为在业务中，我们但部分时间都是放在查询的。

Repository 应该做什么？

Repository ，顾名思义是一个仓库，原则上是对应的一个 Model ，但是也并不强制，用来专门做查询，就像前面的业务，就完全可以封装到 Repository 去。

Service 又应该来做什么？

顾名思义， Service 即服务，就是用来处理一些复杂的场景和数据整合，比如用户注册、用户登录、用户下单、处理三方回调等等这些都可以算作一个复杂的场景。还有数据整合，比如 Dashbroad ，这些地方，为了代码复用的最大化，其中的数据应该是由多个小的 Repository 来进行组成的。再有就是由一些 Service 的 Event 的调度。

Controller 应该来做什么？

• 表单数据验证
• 对 Service 的各种情况进行处理，理想情况下，Service 中出现的所有非理想结果都应该抛出异常，由 Controller 进行捕获后处理给用户。

Model 应该做些什么？

在像 Laravel 这类框架中，Model 其实要做的有很多。比如：

• 作用域(scope)
• 关联关系(relation)
• 表属性(property)
• 模型事件(model event)
• 访问器、修改器
• 序列化

Answer 3

我觉得既然使用Laravel框架了，就不要再过度使用Service这一套了，可以配合使用，但不用太过依赖，Laravel自带的Eloquent Model很强大。
简单的一些逻辑，直接写在Controller就好了，Service我只用来存放复杂的、可复用的业务代码

Answer 4

1. 可以用，但不建议
2. 建议使用依赖注入

从我个人经验来看，非常建议项目中加入一个Service层，甚至有些项目还会加入Logic层，这两个层其实都是虚拟的逻辑上的层。

每个方法只需要关注做它的本职工作，封装越细越自由，但是会增加维护成本，所以我觉得一般增加一层Service就可以了

Service 层是可以复用的，不止处理某个接口请求时调用，其它地方如果用到这块逻辑，同样也可以调用