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

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

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

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

Laravel 的十八个最佳实践

单一职责原则

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

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

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

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

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

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

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

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

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

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

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

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

Pipeline 组件是什么

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

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

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

中文寓意是通道的意思

上代码:

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

使用场景大概如下

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

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

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

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

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

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

好处

php 学习交流群 : 735713840

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