php项目目录的合理划分和Pipeline-组件的使用场景

0次阅读

共计 1444 个字符,预计需要花费 4 分钟才能阅读完成。

php 项目目录的合理划分和 Pipeline 组件的使用场景

这是一篇迟到的文章,很早之前就一直想写了,可是经验不足有些地方理解的不透侧,当然,现在这篇文章可能也是浅尝辄止,希望不要喷我

开篇

首先,可以先导读一下如下这篇文章,有助于提升一下代码质量

Laravel 的十八个最佳实践

单一职责原则

通俗点介绍则是,一个功能为一个功能所做事情。
例如,我们需要获取用户信息,那简而言之,编写的 getUserInfo 则只用它来做一件东西。
当然,这只是一个方法,如果一个类呢,我们需要怎么来定义

如今大家遵循的大多数是 mvc 规范,现在的开发流程下,大概 v,也就是视图层早已经消失殆尽

mc 的关系如何处理呢,我建议大概是如下几种

-app
--Model  // 模型层
--Controller // 控制器层
--Traits 
--Stores // 处理类
--Tools // 工具类
--Routers // 扩展路由

模型和控制器就不需要多说了

  • Traits

    这个名词的解释,Trait 就不多书了,可见官方手册 : https://www.php.net/manual/zh…

    这里主要存放一些复用的公共函数方法,例如获取器,验证器等等,

  • Stores

用来存放模型或者控制器不方便写的一些代码,例如返回一个商品信息,需要针对商品清单从其他数据库或则数据表进行补全完整的信息
例如,购买人次,成交额等等,这个时候,这些东西既不适合交给控制器也不适合交给模型层

  • Tools

工具类,这里存放一些工具方法,例如处理某个数据集的公用或者某个组件功能需要使用的方法
常见的有响应方法,打日志的方法等等

  • Routers

路由扩展文件,这个文件的意义就在于,当系统或者功能庞大起来之后,路由将会变得非常不好管理,基本上在后台管理中,一个功能可能就产生 5 个左右路由

这个时候就需要其将路由文件拆分开来

以上的操作,当然不能一概而论,应当适当的针对业务场景进行处理,例如简单的一个后台,管理用户的功能就无需如此繁杂。当功能越来越多而不好管理的时候才能适当的发挥它的最大作用

重要篇

Pipeline 组件 是什么

参考文章:
【单篇】Laravel Pipeline 组件的实现原理

这是一个非常有趣的功能,大家应该或多或少的使用过中间件,是不是从来没有过去了解中间件呢

其实,中间件背后的逻辑及其实现也就是 Pipeline 的简化版

中文寓意是通道的意思

使用场景

上代码:



如上,我们发现,第一张图我们代码非常非常少,最后一张图,返回的数据字段非常非常多,而查询语句也并没有查询多少东西

使用场景大概如下

有一批商品信息,我们只知道他的商户 id 和商品 id (product 表)
由此,我们需要给前端返回
(订单成交额 order 表)
(分类信息 tag 表)
(成交用户属性信息 user 表)
(优惠信息 coupone 表)

这个时候,按照以往的逻辑,我们有几种解决方案

  • foreach
  • foreach + 类处理

大概第二种方法用的人会最多,循环商品信息,当 if 需要成交额当时候就去成交额的表中查询,然后给补齐上

第一种方法就忽略吧,都是写在一个方法里面来 foreach,极度不推荐

这个时候就 Pipeline 它上场了,通过传导数据给它,在 Pipelinedispatcher 中添加类
例如补齐订单成交额,则可以添加 Order::Class 等等

最大的好处,既是,将功能与功能之间耦合开来,从而即便后续我们需要针对订单成交额的代码逻辑进行修复,也不需要去修改设计到这一整块逻辑的代码

好处

  • 可读性强
  • 符合单一职责原则
  • 耦合度低

php 学习交流群 : 735713840

正文完
 0