打造 Laravel 优美架构 谈可维护性与弹性设计

我的github博客:https://zgxxx.github.io/

公司项目可能需要对架构进行重建,老大给了我一个视频让我学习里面的思想,看完后觉得收获很大,主讲人对laravel项目各个层次有很清晰的理解,力求做到职责单一分明,提高可维护性。下面是我看完视频对其内容的大概整理,以及一些自己的见解,有错误的请指出。
视频:https://www.youtube.com/watch?v=pzY0FBafXd0 (有墙各位懂的)

Laravel简单架构:

avarar

简单的小项目可能会把数据库查询,业务逻辑,数据传给View几乎所有操作都放在Controller,如何项目后期需求变大,最后Controller会变得很臃肿,难懂,不易维护(同样,有些会把所有增删改查,功能类写在Model,Controller再从Model一个个的拿,导致Model很乱,Model有关联表的时候可能会引起一些不必要的数据库查询)

我自己的理解:用美宜佳卖商品给客人来理解,主要Controller是某个加盟商美宜佳门店,View是客人,Model是商品制造工厂(理解有些粗糙)

Repository(商品仓库):

跟Eloquent/DB操作相关的,例如增删改查,直接和数据库打交道的基础操作抽出来放在Repository中,repository中文是仓库,我的理解就是我们要从Model拿数据,先放在仓库repository中,统一由仓库管理分配,发挥仓库的职责
avarar
avarar

Service (总部服务平台):

商业逻辑,不是简单的查询数据,而是特定的任务,例如判断用户是否是会员,设置用户权限等等,这些操作建议放在Service,之后Controller再调用它
avarar
avarar

个人理解:所以在Controller和Model/Eloquent中间垫两层,如果Repository理解为商品仓库的话,我的理解Service是类似总部内部的服务平台,加盟商Controller需要拿商品给客人View,不能直接去食品工厂Model拿,先通过仓库repository,然后总部服务平台Service进行打包啊,整理啊,发车啊(各种任务),最后再给到加盟商Controller手里
avarar

Presenter(充值业务):

一些比较固定,可以单独调用的,可以用Presenter抽出来,不需要让Model去做,下次修改也单独修改Presenter就行了,
例如时间戳转成Y-m-d H:i:s格式,可以单独用Presenter处理后用@inject插入到前端模板,而不是把转化过程写在模板上面
avarar
avarar
avarar
个人理解:所以在Controller和View中间可以加一层Presenter,我的理解有点类似:美宜佳商户(Controller)可以给客人(View)充公交卡,这种小事不需要劳费工厂(Model)
avarar

Transformer(快餐小吃人工筛选):

转换器,例如在仓库repository中有一个获取所有用户信息的查询操作:$this->user->all();
但有些地方我们不需要用到那么多个字段,我只想有name和email字段,难道我要去改all()里面的参数,变成$this->user->all(['name','email'])?
这样另外的地方又要全部字段,这不就冲突了?这时候Transformer就有用了,其实原理是对$this->user->all()获得的数据进行筛选后再输出,加了个筛选器。
avarar
avarar
avarar
之后要修改结果字段就直接在transform修改即可,当然还可以额外添加需要的字段:array_set()
avarar
个人理解:这一块我的理解就是有些客人需要点一些快餐,例如美宜佳里面的车仔面呀,烤肠呀,在卖出商品的时候需要根据客人的需求对小吃进行筛选再卖出去,不可能客人指点要一个烤肠,你把店里全部小吃拿给他,让他自个去筛选,中间卖出去的时候需要Transformer进行筛选再给出商品
avarar

Formatter(包装):

主要用于保持API返回格式的一致(使用方法和transform类似):
avarar
avarar
avarar
个人理解:Formatter这一块我的理解就是商品包装,客人买东西,买小吃,你需要对商品先进行包装,当然这个包装肯定需要保持一致
avarar
以上便是我再看完视频后对其进行总结整理,当然理论的说的容易,实际操作起来还有很多未知的问题,还是需要后面继续研究学习。

本帖由系统于 4个月前 自动加精
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
《L04 微信小程序从零到发布》
从小程序个人账户申请开始,带你一步步进行开发一个微信小程序,直到提交微信控制台上线发布。
讨论数量: 21
Atzcl

大佬,这视频地址没发对呀~

4个月前

@Atzcl 改好了哈

4个月前
Atzcl

@zgxxx 看完了,就是这个文章的视频版: https://oomusou.io/laravel/architecture/,这样的架构可能会导致整个项目会很肥大~

4个月前

@Atzcl 是的,一开始我们把这几个新的层次都加进去后发现,其实有些是没必要的,只会多写一些重复的代码,没什么实质性的代码,所以后面只有Service,加transform,formatter做成一个trait,基本就可以了,看自己项目的需求吧

4个月前

绕来绕去,IO快没了

4个月前

湾湾搞的,太啰嗦了。基本加一个 Service 就足够了

4个月前
yema

怎么弄像java的。就差个bean了。

4个月前

和我公司的架构一样 , 各取所需 .

4个月前
kenuo

太复杂了. php 性能本来就不好.白白实例化这么多类

4个月前
hareluya

千万不要把controller放在中间。

4个月前

@JaguarJack 中小项目只要 services 确实行,但项目比较大的呢?而且如果没有 Repository ,比如数据库查询,那么只能放在 services 或者 model 里面,如果放在 services 里面,那么这里就是既有逻辑代码,又有查询代码,代码一多呢?如果放在 model 里面,那么 scope 查询器修改器查询语句等等... 全在 model ,所以放在 model 或 service 都会造成责任不单一与臃肿, model 如果只放关联之类的操作, scope 与 访问器修改器以及数据库查询放在 Repository 里面,会不会更清晰呢,职责更单一呢

4个月前

@FreeMason 大型项目不会考虑 php

4个月前

你的文章标题起得太“震惊”,请先看看领域驱动设计,对于软件架构设计的想法会有完全不一样的认知,你现在的设计只是在MVC的基础上更细分而已,你的模型依然是贫血模型,没有本质上对实现业务的契合

4个月前

你好像搞错了(公司项目可能需要对架构进行重建)的含义。

2个月前
gangpula

service很必要,不论什么框架,自己不加了话,那就只剩控制器和模型,逻辑就只能写控制器里。这怎么行呢
laravel model被弱化了,加这个Repository层,感觉还行。但别的框架在Repository封装sql方法还是model里写sql方法我感觉区别不大。
transform用过感觉不错

2个月前
陈伯乐

Laravel 本身就有 Model Resource 了,Formatter 感觉有点多余

2个月前
Egfly

个人感觉,repository +service +transform+ controller应该就足够。再多久太臃肿了

2个月前
不温柔

具体项目具体分析,主要需要看工程项目的体量,复杂度,人员配置

2个月前
沈益飞

公司项目开始的时候用的是 Model\Eloquent + Controller + Transformer 完全能够支撑,后来体量大了,需求复杂了,就会发现 Controller 代码会变得很臃肿,并且不太适合编写单元测试,导致重构代码的时候单元测试覆盖不够到位。目前是将主要复杂部分业务逻辑使用 Service + Repository 重构。如果后期项目在肥大了,考虑使用微服务。

2个月前
jaak

laravel社区的网站代码也没搞这么复杂吧。。。

2个月前

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!