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

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 它上场了，经过传导数据给它，在 Pipeline 的dispatcher中添加类
例如补齐订单成交额，则能够添加 Order::Class 等等

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

好处

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

php学习交流群 : 735713840