Laravel的中大型项目构架

初学者学习Laravel时分两种,一种是乖乖的将程序填入MVC构架内,导致controller与model异常的肥大,日后一样很难维护;一种是常常不知道程序该写在哪一个class内而犹豫不决,毕竟传统PHP都是一个页面一个文件。本文整理出最适合Laravel的中大型项目构架,兼具容易维护、容易扩充与容易重复使用的特点,并且容易测试。

Controller过于肥大

Ruby on Rails的影响,初学者常认为MVC构架就是modelviewcontroller

Model就是数据库。

Controller负责与HTTP沟通,调用model与view。

View就是HTML。

假如依照这个定义,以下这些需求该写在哪里呢?

  • 发送Email,使用外部API。
  • 使用PHP写的逻辑。
  • 依需求将显示格式作转换。
  • 依需求是否显示某些数据。
  • 依需求显示不同数据。

其中1,2属于商业逻辑,而3,4,5属于显示逻辑,若依照一般人对MVC的定义,model是数据库,而view又是HTML,以上这些需求都不能写在modelview,只能勉强写在controller

因此初学者开始将大量程序写在controller,造成controller的肥大难以维护。

Model过于肥大

既然逻辑写在controller不方便维护,那我将逻辑都写在model就好了?

当你将逻辑从controller搬到model后,虽然controller变瘦了,但却肥了modelmodel从原本代表数据库,现在变成还要负担商业逻辑与显示逻辑,结果更惨。

Model代表数据库吗?把它想成是Eloquent class就好,数据库逻辑应该写在repository里,这也是为什么Laravel 5已经没有models目录,Eloquent class仅仅是放在app根目录下而已。

中大型项目构架

那我们该怎么写呢?别将我们的思维局限在MVC内:

Model:仅当成Eloquent class

Repository:辅助model,处理数据库逻辑,然后注入到service

Service:辅助controller,处理商业逻辑,然后注入到controller

Controller:接收HTTP request,调用其他service

Presenter:处理显示逻辑,然后注入到view

View:使用blade将数据bindingHTML

中大型项目构架

其中蓝色为原本的MVC,而紫色为本文要介绍的的重点:Repository模式,Service模式与Presenter模式。箭头表示物件依赖注入的方向。

我们可以发现MVC构架还在,由于SOLID的单一职责原则与依赖反转原则:

1、我们将数据库逻辑从model分离出来,由repository辅助model,将model依赖注入进repository

2、我们将商业逻辑从controller分离出来,由service辅助controller,将service依赖注入进controller

3、我们将显示逻辑从view分离出来,由presenter辅助view,将presenter依赖注入进view

建立目录

在 app 目录建立 RepositoriesServicesPresenters 目录。

Laravel的中大型项目构架

别害怕在Laravel预设目录以外建立的其他目录,根据SOLID的单一职责原则,class功能越多,责任也越多,因此越违反单一职责原则,所以你应该将你的程序分割成更小的部分,每个部分都有它专属的功能,而不是一个class功能包山包海,也就是所谓的万能类别,所以整个项目不应该只有MVC三个部分,放手根据你的需求建立适当的目录,并将适当的class放到该目录下,只要我们的class有namespace帮我们分类即可。

Repository

由于篇幅的关系,将repository独立成专文讨论,请参考如何使用Repository模式

Service

由于篇幅的关系,将service独立成专文讨论,请参考如何使用Service模式

Presenter

由于篇幅的关系,将presenter独立成专文讨论,请参考如何使用Presenter模式

单元测试

由于现在modelviewcontroller的相依物件都已经拆开,也都使用依赖注入,因此每个部分都可以单独的做单元测试,如要测试service,就将repository加以mock,也可以将其他service加以mock

Presenter也可以单独跑单元测试,将其他service加以mock,不一定要跑验收测试才能测显示逻辑。

总结

本文谈到的构架只是开始,你可以依照实际需求增加更多的目录与class,当你发现你的MVC违反SOLID原则时,就大胆的将classMVC拆开重构,然后依照以下手法:

1、建立新的class或interface。

2、将相依物件依赖注入到class。

3、在class内处理他的职责。

4、将class或interface注入到controller或view。

最后搭配单元测试,测试重构后的构架是否与原来的需求结果相同。

相关文章

感觉本篇文章不错,对你有收获?

¥我要小额赞助,鼓励作者写出更好的教程
80 160 120

作者:

  • 出处: https://www.mi360.cn/articles/187
  • 本文版权归作者,欢迎转载,但未经作者同意必须保留 此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

评论区

最新评论

扫码关注