什么?快来开启 MVC 的 “拓展 “模式

前言

对于MVC,我想大家都特别熟悉了吧,即使刚刚入门PHP。初学者学习Laravel的时候大部分都将程序填入MVC构架内,导致controller与model异常的肥大,日后一般维护艰难(我一开始就这样)。

关于MVC的“虚假理解”?

Ruby on Rails的影响,我们简单的就把MVC理解成model用来从数据库获取数据的、view用来显示页面的,controller用来接收model获取的数据并分配展示view的。真的是这样吗?


当然,我想这在一个小型的项目里面是不会有太大问题的,因为你的用户仅仅只是很少一部分人,甚至说只有几十人,当然不会有太大的问题,但是如果有上万人呢?我想可能不行了吧。这个时候,我们应该开启MVC隐藏的拓展模式。


什么?快来开启MVC的“拓展“模式
如图,我们把model当成Eloquent class,用一个处理数据库逻辑的Repository来辅助它,同样对于controller来言,它也有一个辅助它的功臣,那就是能处理商业逻辑Service,这样就解决了臃肿的问题,view呢?我们是不是忽略了它,并不是的,它也有属于它的处理显示逻辑的Presenter


这就是拓展模式?

是的,这就是MVC的拓展模式,也许它并不叫做拓展模式,但是我习惯这样叫它。让我们再一次更深入的看一下上面的那张图,蓝色的是原来的MVC,而粉色的(当然也有人说是紫色的,但是没有关系)是我接下来要说的:Repository模式,Service模式与Presenter模式。箭头表示物件依赖注入的方向。


我们可以发现MVC构架还在,由于SOLID的单一职责原则与依赖反转原则:我们将数据库逻辑从model分离出来,由repository辅助model,将model依赖注入进repository。同样我们将商业逻辑从controller分离出来,由service辅助controller,将service依赖注入进controller。显示逻辑也从view分离出来,由presenter辅助view,将presenter依赖注入进view。这样写就避免了臃肿和后期维护的不方便。


结束语

由于篇幅和时间的关系,就先介绍这么多,如果你有更好的意见或者建议,欢迎纠正或者联系我,希望对同样正在学习的你有所帮助。

本作品采用《CC 协议》,转载必须注明作者和本文链接
空舟湖上~      ——Jouzeyu
本帖由系统于 4年前 自动加精
lochpure
《L04 微信小程序从零到发布》
从小程序个人账户申请开始,带你一步步进行开发一个微信小程序,直到提交微信控制台上线发布。
《G01 Go 实战入门》
从零开始带你一步步开发一个 Go 博客项目,让你在最短的时间内学会使用 Go 进行编码。项目结构很大程度上参考了 Laravel。
讨论数量: 4
yourself

个人理解repository不是用来封装model,如果只是用来封装model不如直接写个基类继承。
repository是为了service在获取数据的时候可以不用关心你到底是用什么方式存储的,也就是不管你是redis还是mysql,es等等方式存储的数据,service只需要数据不关心你怎么实现,并且如果有一天需要更换存储引擎的时候,替换绑定就可以了,不需要在调用方做更改。

4年前 评论
Epona

我最开始学习Laravel的时候,他们就是使用的 Repository 模式。 不过我现在已经不喜欢这种设计模式了😂。

4年前 评论
lochpure (楼主) 4年前
L学习不停 4年前
Epona (作者) 4年前
arunfung 4年前
JaguarJack

现项目就是 repository + service 模式,controller 只有返回。不做任何处理

4年前 评论

主要laravel 的model太强大,以至于很多时候repository有点鸡肋,毕竟绝大部分查询都是一行的事,不过service还是必要的。除非应用对性能要求很高,以至于很多时候不用自带的关联模型,获取器等特性,需要直接sql什么的。

4年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!