Laravel 中大型项目构架

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

Controller过于肥大

受RoR的影响,初学者常认为MVC构架就是model,view,controller:

Model就是数据库。

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

View就是HTML。

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

发送Email,使用外部API。

使用PHP写的逻辑。

依需求将显示格式作转换。

依需求是否显示某些数据。

依需求显示不同数据。

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

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

Model过于肥大

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

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

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将数据binding到HTML。

5a426dd9e6cc9.png

其中蓝色为原本的MVC,而紫色为本文要介绍的的重点:Repository模式,Service模式与Presenter模式。

箭头表示物件依赖注入的方向。

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

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

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

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

建立目录

在 app 目录建立 Repositories,Services 与 Presenters 目录。

image.png

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

Repository

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

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

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

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

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

Conclusion

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

建立新的class或interface。

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

在class内处理他的职责。

将class或interface注入到controller或view。

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