中型Laravel项目架构(二) - 控制器和模型
中型Laravel项目架构(二) - 控制器和模型

在上篇文章中,我介绍了路由层和中间件层可以优化的地方,此篇便开始介绍中型Laravel架构中普遍存在的问题:控制器和模型

很多人在初次接触到Laravel此类MVC框架的时候,开发没有任何规范,完全靠着Laravel项目路径在走,控制器写逻辑代码,模型写数据层代码,刚开始的逻辑代码可能全部都堆积在控制器,后来日益增加的复用压力,让很多人把代码写到了模型层,导致无论是控制器还是模型里,都堆积着大量冗余的代码,给复用,重构,都带来不小的压力和不便。

User的Model里面包含着非常多的逻辑代码:

Service 和 Repository

为了解决代码过于冗余的问题,最简单的方法就是将代码逻辑分更多的层,只有更细的粒度,才能更好的复用,所以,引入了 ServiceRepository,那么既然都是 ControllerModel 之间一层,那么这两层有什么区别呢?正如上图所表示的:

  • Service 层更加贴近业务逻辑,复杂的逻辑在这里开始分解,组合。
  • Repository 层更加贴近数据逻辑,对数据库的读写操作。

有了ServiceRepository,那么ControllerModel功能就大大弱化了,但还是有非常重要的作用。

  • Controller 用来接收通过路由传递过来的数据,并对数据进行清洗和整理,递交给 Service
  • Model 仅仅当做Eloquent的类,无其他实质作用。

整个结构划分的过程中,我们要谨记SOLID原则中的两个原则:单一职责依赖注入单一职责前面已经说过,依赖注入是通过Laravel特性完成。

代码示例

通过一个简单的用户创建的例子,来说明Controller Repository ServiceModel如何配合起来的。

在接受到从路由传递过来的参数,Controller对参数进行接受和处理,并调用Service实现逻辑:

我们可以看到,Service 的调用,并不是通过实例化来实现的,而是通过依赖注入的方式,后面 Service 调用 Repository也是同样的方式。

可以看到,Controller 里面基本是没什么逻辑代码的,仅仅只作接受和响应的处理。

Service 中,所有的逻辑代码都是在这里,首先检查一下手机已经注册,如果没注册就进行创建操作,这里只是实现逻辑,而具体数据层的实现,则放在 Repository中。

小结

知道如此对代码分层,这就需要我们写代码的时候,要有一定的构思,更低粒度的数据层操作放在 Repostory,代码逻辑放在Service,围绕这两点,代码则会越来越精简,复用性更加地好。


If You Have Any Question, You Can Contact Me Through liam@blue7wings.com, @Blue7Wings, #Liam_Hsia