deepwell/think-event

thinkphp6事件系统拓展

v1.0.1 2022-10-16 03:11 UTC

Requires

• php: >=7.4
• topthink/framework: ^6.0

MIT

• deepwell

• event
• thinkphp6

README

介绍

topthink/think-event拓展

tp6事件系统采用了面向对象中的观察者模式进行设计，是AOP的一种实现。

本项目基于事件监听方式，对事件系统的扩展，通过预埋观察点，实现水平拓展，有效减少应用之间、模块之间的耦合

新增了哪些特性

• 多应用模式下全局有效
• 事件中的监听赋予唯一标识
• 事件触发后返回结果，有两种模式：
  • 将每次监听结果与事件参数合并，并传递到下一个监听中，合并每次监听的结果，作为事件返回值
  • 将每次监听结果作为事件参数传递到下一个监听中，将最后一个监听结果作为事件返回值
  • TODO使用对象作为事件入参出参,代替array入参出参
• 事件监听支持取消
• 事件监听支持设置优先级

使用方法

应用的event目录存放监听注册文件，listener目录存放监听处理类文件

事件分组

假如一个系统有多种类型的订单（电商、外卖、预约等），使用了order type区分，为了减少业务复杂度，在触发商品服务和订单服务中的事件时，根据order type进行了分组，如果是活动订单，会将活动ID对应的字符串作为分组标识；

如订单计算服务(以电商订单为例)：

触发的事件名称是：OrderCalculate.1，1是电商的order type值（事件对应的监听器配置，可以在多处定义）

编排电商订单计算事件监听器如下所示：

用星号来分组，表示通配，即事件触发时，会默认自动将通配的监听器注入到其他分组中。如果子分组不需要通用的监听器，在编排分组监听时，通过传入监听管理器按需设置。

比如次卡下单流程，不需要联系人信息，也不需要关联推广订单信息，通过传入管理器并设置不使用通用配置，编排如下：

如此次卡下单流程便不会触发检查联系人、生成推广订单事件。

监听器

一个自定义类实现ListenerInterface后成为监听器

title：监听器功能描述

priority：监听器优先级，数值越大，越先执行

上一节的事件分组，可能会让人产生疑问，在多个应用中编排某个事件的监听，如何让事件中的监听按照理想的执行顺序执行呢？答案是：调整监听器的priority大小。

通过函数event_listeners()获取项目中事件监听的概况：

dd(event_listeners(EventsMapping::ORDER_CALCULATE . '.' . OrderMapping::ORDER_TYPE_ECSHOP));