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

我的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
以上便是我再看完视频后对其进行总结整理,当然理论的说的容易,实际操作起来还有很多未知的问题,还是需要后面继续研究学习。

本帖由系统于 1周前 自动加精
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
讨论数量: 14
Atzcl

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

1周前

@Atzcl 改好了哈

1周前
Atzcl

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

1周前

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

1周前

绕来绕去,IO快没了

1周前

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

1周前
yema

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

1周前

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

1周前
kenuo

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

1周前
hareluya

千万不要把controller放在中间。

1周前

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

6天前

@FreeMason 大型项目不会考虑 php

6天前

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

6天前

  • 请注意单词拼写,以及中英文排版,参考此页
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`, 更多语法请见这里 Markdown 语法
  • 支持表情,使用方法请见 Emoji 自动补全来咯,可用的 Emoji 请见 :metal: :point_right: Emoji 列表 :star: :sparkles:
  • 上传图片, 支持拖拽和剪切板黏贴上传, 格式限制 - jpg, png, gif
  • 发布框支持本地存储功能,会在内容变更时保存,「提交」按钮点击时清空
  请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!