资讯专栏INFORMATION COLUMN

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

Amio / 2577人阅读

摘要:公司项目可能需要对架构进行重建,老大给了我一个视频让我学习里面的思想,看完后觉得收获很大,主讲人对项目各个层次有很清晰的理解,力求做到职责单一分明,提高可维护性。

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

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中有一个获取所有用户信息的查询操作:
$this->user->all();但有些地方我们不需要用到那么多个字段,我只想有name和email字段,难道我要去改all()里面的参数,变成
$this->user->all(["name","email"])?这样另外的地方又要全部字段,这不就冲突了?这时候Transformer就有用了,其实原理是对$this->user->all()获得的数据进行筛选后再输出,加了个筛选器。


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

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

Formatter(包装):

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


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

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

附上个人简易博客:https://zgxxx.github.io/ 欢迎讨论

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/29412.html

相关文章

  • 优秀文章收藏(慢慢消化)持续更新~

    摘要:整理收藏一些优秀的文章及大佬博客留着慢慢学习原文协作规范中文技术文档协作规范阮一峰编程风格凹凸实验室前端代码规范风格指南这一次,彻底弄懂执行机制一次弄懂彻底解决此类面试问题浏览器与的事件循环有何区别笔试题事件循环机制异步编程理解的异步 better-learning 整理收藏一些优秀的文章及大佬博客留着慢慢学习 原文:https://www.ahwgs.cn/youxiuwenzhan...

    JeOam 评论0 收藏0
  • 程序员黑客

    摘要:记录自余弦在上的演讲程序员与黑客防御就是提高攻击的成本架构思想一黑客思维应该贯穿整个公司的业务架构研发运维理想状态技术团队每个人都有黑客思维思想二优美的架构一定是健壮的想象下生态系统有漏洞被黑很正常快速自愈是关键思想三优美的架构一定 记录自余弦在qcon上的演讲 程序员与黑客(1) 防御就是提高攻击的成本 架构 思想一:黑客思维应该贯穿整个公司的业务[..->架构->研发->运维->....

    qieangel2013 评论0 收藏0
  • 云计算 Cloud Native | 数人云CEO王璞@KVM分享实录

    摘要:分享实录云计算技术源于互联网公司,现在云计算已经是下一代企业级的发展趋势。如何做云计算一直是云计算技术的领导者。互联网公司的快速发展,已经印证了云计算技术和云原生应用相比传统构架的巨大优势。 今天小数又给大家带来一篇干货满满的分享——来自KVM社区线上群分享的实录,分享嘉宾是数人云CEO王璞,题目是《云计算与 Cloud Native》。这是数人云在KVM社区群分享的第一弹,之后还有数...

    _Zhao 评论0 收藏0
  • 架构升级,微服务落地GIStack for Manager

    摘要:第二种则由多个小单元构成,每个小单元都是独立的服务。微服务架构所依赖的弹性通信轻量等需求容器恰好可以完美提供,因此微服务与容器可以说是完美的一对。谈到架构,微服务架构已然是时至今日必聊的一个话题,系统架构的选型与是否转型,不应该是为了微服务架构而架构,而是源于微服务架构自身是否更适合业务自身的需求,微服务架构的优势与所要付出的代价是否值得你,去做一次转变。    GIStack for M...

    bingchen 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<