【Laravel】对架构的一点拙见

公司现在使用的Laravel框架,是一种典型的MVC框架。现阶段开发中我们追求”版本上线速度“,将代码填入MVC框架中,这样导致的问题是Model和Controller中代码非常多,日后将会很难维护。后期会出现增加新的功能时发现需要变动的地方很多(说不定手抖写了BUG)。一个好的项目结构可以说非常重要,比如前端代码结构就很清晰,使用起来是不是非常舒服呢。我们项目后端代码的结构应该页具备这些特征:容易维护,容易扩展,容易复用,容易测试。下面请看我的一点拙见。

Controller过大

Model就是数据库,Controller与HTTP沟通,调用Model与View。View就是前端代码。按照这个定义,下面的需求应该写在哪里:

1.利用Laravel写的业务逻辑。

2.上传文件到七牛云,使用外部的API。

很明显,如果按照一般的MVC思想,Model是数据库,而View是前端代码,上面这些需求都不能写在Model和View中,只能写在Controller中。这将会导致Controller代码量非常大,不易维护。

Model过大

如果代码逻辑写在Controller中不方便维护,我们将逻辑写在Model中。

虽然Controller代码量变小了,但是Model代码量就变多了。既然Model代表数据库,把它想象成Eloquent class就好了。不违背面向对象-单一职责原则。可能是这个原因Laravel5中没有了models目录,而是把Model文件放在App目录下。

View过大

我们在处理显示逻辑的时候经常会遇到这些情况:根据用户的权限是否显示某些数据,根据需求显示不同的时间格式等等。现阶段我们几乎将整个显示逻辑都写在view中,这样将会导致View中Blade与HTML混杂,View代码量变大。

新的结构

那我们应该怎么写呢?在这种情况下我去查阅了Github上一些优秀开源代码,以及之前在做J2EE时的知识,总结如下:

Model:仅当成Eloquent class.

Respository:辅助Controller,处理数据库逻辑。

Service:辅助Controller,处理业务逻辑。

Controller:接受Http请求,调用service。类似于一个调度者的作用。

Presenter:处理显示逻辑,通过@inject标签(Laravel文档中有提及)将Presenter注入到View中。

View:绑定数据。

2018-01-27 16-41-59屏幕截图.png

Laravel中有一个IOC容器的概念,可以简单理解成一个装了很多类的容器,当我们需要这个类时。就可以通过类似KEY-VALUE的形式去容器中取相关对象(大家有兴趣可以跟踪一下Laravel的源代码)。我们将所有的Service,Controller等通过IOC容器建立关联,解决了类之间的耦合。另外使用Trait(特性)也是对这个项目结构的一种补充手段,比如项目中有一个关注模块,我们可以将他们抽取出来,在使用的地方use进去就行。

上面的简图如下:

5a426dd9e6cc9.png

将项目的结构细分成这么多块,会觉得麻烦?No,这样分确实可以方便我们维护自己的项目,并不属于过度设计。《敏捷式软件开发》中提到面向对象的单一职责原则,class功能越多,责任越多,因此违反了单一职责原则,所以应该将程序划分成更小的模块。不仅仅是对于这个项目整体,对于类我们也要做到如此,比如我们在一个类中的方法中写了一个巨大的方法,这个时候就要考虑抽取了,抽取能提高代码可读性(伙伴通过方法名就可以知道你这段代码写的是什么意思),抽取能提高方法的复用性(不断抽取将会降低方法功能的粒度,这样复用性就越高),比如项目中截取图片尺寸这个操作我们可以将它抽取出来。做为一个team,团队的协作很重要,而这些有用的模式将会降低我们沟通的成本。

欢迎大家点评~

日记本

如果觉得我的文章对您有用,请随意赞赏。您的支持将鼓励我继续创作!

赞赏支持
被以下专题收入,发现更多相似内容