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

2018年9月13日 272点热度 0人点赞 0条评论

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

Laravel简单架构:

图片

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

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

Repository(商品仓库)

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

图片

图片Service(总部服务平台)

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

图片图片

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

图片

Presenter(充值业务)

一些比较固定,可以单独调用的,可以用Presenter抽出来,不需要让Model去做,下次修改也单独修改Presenter就行了,例如时间戳转成 Y-m-d H:i:s 格式,可以单独用Presenter处理后用@inject插入到前端模板,而不是把转化过程写在模板上面。

图片

图片

图片

个人理解:所以在Controller和View中间可以加一层Presenter,我的理解有点类似:美宜佳商户(Controller)可以给客人(View)充公交卡,这种小事不需要劳费工厂(Model)。

图片

Transformer(快餐小吃人工筛选)

转换器,例如在仓库repository中有一个获取所有用户信息的查询操作:

  1. $this->user->all();

但有些地方我们不需要用到那么多个字段,我只想有name和email字段,难道我要去改all()里面的参数,变成:

  1. $this->user->all(['name','email']);

这样另外的地方又要全部字段,这不就冲突了?这时候Transformer就有用了,其实原理是对 $this->user->all() 获得的数据进行筛选后再输出,加了个筛选器。

图片

图片

图片

之后要修改结果字段就直接在transform修改即可,当然还可以额外添加需要的字段: array_set()

图片

个人理解:这一块我的理解就是有些客人需要点一些快餐,例如美宜佳里面的车仔面呀,烤肠呀,在卖出商品的时候需要根据客人的需求对小吃进行筛选再卖出去,不可能客人指点要一个烤肠,你把店里全部小吃拿给他,让他自个去筛选,中间卖出去的时候需要Transformer进行筛选再给出商品。

图片

Formatter(包装)

主要用于保持API返回格式的一致(使用方法和transform类似)。

图片

图片

图片

个人理解:Formatter这一块我的理解就是商品包装,客人买东西,买小吃,你需要对商品先进行包装,当然这个包装肯定需要保持一致。

图片

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


欢迎关注 SegmentFault 微信公众号 :)

图片

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

root

这个人很懒,什么都没留下

文章评论