Yii2基本概念之——事件(Event)
说起事件(event),我们可是一点都不陌生。现实生活当中的事件无处不在,比如你发了一条微博,触发了一条事件,导致关注你的人收到了一条消息,看到你发的内容;比如你通过支付宝买东西,付了款,触发一个事件,导致你收到一条短信,告诉你刚刚扣款了,你账户余额还有多少…
我们将事件稍稍加以抽象,发现事件具有某些共同特点,比如事件其实不是孤立存在,它只是某个流程或者工序的一个特殊的“点”,可以理解为时间点,也可以理解为逻辑的点;其次,事件上可以绑定一些“动作”,比如发送一条短信或者发送一个邮件;第三,我可以绑定,当然也可以解绑,如果我反感频频的短信提醒,我可以选择不发短信,我自己去查看账户余额;第四,这些动作和主流程往往并没有直接的关系,往往是“附加”的:我已经付完款了,你发短信或者不发,发邮件或者直接客服通知我其实影响不大,并不影响我购物这个行为本身——反正我已经付完款,预期不久就会收到商品了。
其实,说到这里,已经有点入戏的感觉了。人有生老病死,一年有春夏秋冬四季演替,封建王朝有兴盛、停滞、衰亡的周期律——“其兴也勃焉,其亡也忽焉”。换句话说,人,季节,王朝等等这些世间万物都有自己的生命周期。
那么在软件行业,一个系统,一个组件,一个功能,一个类都是有自己的生命周期的——创建、运行、销毁。比如一个类(Class)都要经过__construct()
,调用各个类方法,__destruct() 的过程。每个程序的运行,要理解为一个过程或者流程。那么这样来理解事件就有意义了:事件无非就是这个过程之中一些有意义的“点”。这些点是人为做的设定,比如插入数据库数据,那么校验前、后,插入前、后就可能是几个有意义的时间节点,把这些节点看成一个个的事件,就更加便于我们去理解这整个过程。复杂的东西理解起来困难,我们分成若干个阶段来理解岂不是就简单许多了吗?想想为啥计算机网络为啥要分成物理层、数据链路层、网络层,运输层、应用层这个简单道理就行了。除了我们更好的去理解程序的运行流程,更为重要的是还能够使我们能够“介入”这个流程,改变这个流程,从而实现我们的目的。这就是往事件上“附加”一些动作或者行为了,专业点说,就是事件处理器或者事件监听者。我们想要在某个特定的时间点做点什么,就事先在这个对应的事件上绑定事件处理器,当流程走到这一步时,相应的处理器就被执行,完成我们事先设定的目的。想象一下:软件的运行就是沿着自己设定的路线,走过一个又一个重要节点,同时触发这些节点事件,最终走到自己生命终点的一个过程。将事件理解为流程中的节点,不仅可以帮我更好的认识程序,也能更好的帮助我们改造程序。
事件的实现,其实是观察者模式的一种体现。可能有人会说,为啥是观察者模式?Yii的事件并不符合观察者模式的经典定义啊?的确,Yii的事件实现机制中确实不存在经典Observer和Subject即观察者和被观察者。但是,不要在意这些细节——观察者模式主要面临场景是一对多松耦合的对象之间的关系,要解决的问题就是对象状态改变,其他对象能得到通知。“一对多”和“松耦合”
是其核心要义和功能。看看Yii的事件其实正好能实现这两个功能:Yii的每个事件(beforeSave,afterSave这些)都是一个被观察者,每个事件处理器都是它的观察者,被观察者被触发时,所有观察者都依次要执行。
小编心得:观察者模式的经典定义——观察者模式定义了对象之间的一对多依赖,这样一来,当一个对象改变状态时,它的所有依赖者都会受到通知并自动更新。
下面,我们来谈谈Yii2本身是如何实现事件的。
事件相关的类
在Yii中,事件是Component引入的,BaseObject 是不支持事件的,BaseObject只支持属性。当你需要使用事件时,就需要继承Component或者它的子类,而不能直接继承BaseObject。好在我们之前反复提过,Yii2是基于Component的,就是说,Yii2中大部分类都是Component的子类,是天生带有事件功能的。和其他框架相比,我觉这是Yii2的一大优势——从“原子”层面都已经让类具备很强的扩展性了。面对具体业务场景,事件往往成为一把利剑,使得使用者得心应手。同时,\yii\base\Event是于Yii2事件功能紧密相连的一个类,他封装与事件相关的有关数据,并可以自定义一些功能函数作为辅助。
class Event extends BaseObject
{
// 事件的名称
public $name;
// 事件发布者,通常是调用了 trigger() 的对象或类,也可传递别的对象。
public $sender;
// 此事件是否被处理了,若为true,那事件的处理到此为止
public $handled = false;
// 事件的相关数据
public $data;
// 保存全局事件的处理器
private static $_events = [];
// 绑定类级别事件handler
public static function on($class, $name, $handler, $data = null, $append = true)
{
// ...
}
// 取消类级别事件handler的绑定
public static function off($class, $name, $handler = null)
{
// ...
}
// 解绑所有类级别事件的handler
public static function offAll()
{
self::$_events = [];
}
// 判断一个类和其所有父类上是否绑定有事件处理器
public static function hasHandlers($class, $name)
{
// ...
}
// 触发类级别的事件,执行所有这个事件上绑定的handler
public static function trigger($class, $name, $event = null)
{
// ...
}
}
事件处理器
所谓事件处理器(事件handler)就是事件处理程序。“触发事件”和执行“事件处理器”其实是一个意思。说到底,事件处理器到底是什么呢?其实仅仅只是一个callable——或者是全局函数,或者是类的方法等。本质上说,事件处理器就是一段PHP代码,一个PHP函数。
具体说来,handler 有这么几种形式:
- 匿名函数
function ($event) { ... }
- 对象的方法
$object->handleClick() 即 [$object, 'handleClick']
- 类的静态方法
Page::handleClick()
- PHP系统函数或者自定义全局函数 trim,array_filter,handleClick等,注意只是函数名,不需要带任何参数
无论是哪种形式的handler,它们最终都必须要有如下的形式:
function ($event){...}
这里的$event正是yii\base\Event类或者其子类的实例。
事件的绑定和解绑
有了事件处理器,就可以将其绑定到特定的事件上了。绑定事件处理器是通过yii\base\Component::on()
来进行,相应的解绑是yii\base\Component::off()
。
绑定
// 绑定的过程就是将handler写入$_event[]的过程
public function on($name, $handler, $data = null, $append = true)
{
$this->ensureBehaviors();
//$append为true时$handler置于数组最后,触发时最后被执行
if ($append || empty($this->_events[$name])) {
$this->_events[$name][] = [$handler, $data];
} else { //$append 为false时$handler置于数组最前,触发时最先被执行
array_unshift($this->_events[$name], [$handler, $data]);
}
}
例如:
$order = new Order();
$order->on(Order::EVENT_CREATING, [$obj, 'verifyOrder',false]) ;
$order->on(Order::EVENT_CREATED, 'checkOrder') ;
$order->on(Order::EVENT_PAYED, ['\common\lib\Email', 'send']) ;
$order->on(Order::EVENT_PAYED, function ($event) {
echo '订单已经支付';
});
绑定事件处理器时可以提供额外数据作为 \yii\base\Component::on() 方法的第三个参数,数据在事件被触发时能被处理器使用。如:
// 第三个参数传递数据,当订单被支付时输出'订单已支付'
$order->on(Order::EVENT_PAYED, function ($event) {
echo $event->data;
}, '订单已支付');
事件处理器的绑定可以如上在运行的时候进行,也可以在配置的进行绑定。无论哪种方式,都必须是先绑定,后触发。
解绑
public function off($name, $handler = null)
{
$this->ensureBehaviors();
if (empty($this->_events[$name])) {
return false;
}
// 如果没有传递$handler参数,那么解绑事件$name名下的所有handler
if ($handler === null) {
unset($this->_events[$name]);
return true;
}
$removed = false;
// 如果传递参数$name,那么解绑$name下特定的handler:$handler
foreach ($this->_events[$name] as $i => $event) {
// 注意$event的第一个元素是hanlder,第二个是$data
if ($event[0] === $handler) {
unset($this->_events[$name][$i]);
$removed = true;
}
}
if ($removed) {
$this->_events[$name] = array_values($this->_events[$name]);
}
return $removed;
}
解绑的例子:
// 解绑事件下所有的事件处理器
$order->off(Order::EVENT_CREATING) ;
// 解绑事件下checkOrder处理器
$order->off(Order::EVENT_CREATED, 'checkOrder') ;
一般来说,可以通过on绑定的handler,都可以通过off来解绑。但是匿名函数是除外的,你不能解绑某个特定的匿名函数,除非你事先将其保存为变量,而后通过这个变量来指定其解绑。
$myHandler = function($event) {....}
$order->on(Order::EVENT_CREATED, $myHandler);
$order->off(Order::EVENT_CREATED, $myHandler);
保存handler的数据结构
在Component中$_events专门用来维护这些handler:
private $_events = [];
这里写图片描述
事件的绑定逻辑是这样的:
- 参数 _event[] 数组的最后面。这也是默认的绑定方式。
- 参数 $append 是否为 false ,表示handler要放在数组的最前面。
- 如果事件还没有绑定任何handler,那么无论_event[EVENT_NAME][]只有这么一个元素,既是第一个也是最后一个
handler在 $event[] 数组中的位置就代表执行的先后顺序,在现实生活中往往意义重大。
事件的触发
事件通过Component::trigger()来触发,触发本质就是执行事件handler的过程。
$order->trigger(Order::EVENT_CREATED);
源码如下:
public function trigger($name, Event $event = null)
{
$this->ensureBehaviors();
if (!empty($this->_events[$name])) {
// 执行handler必须传递一个Event实例,用来传递数据
if ($event === null) {
$event = new Event();
}
// 指定是谁触发的这个事件,默认就是trigger调用者自身
if ($event->sender === null) {
$event->sender = $this;
}
$event->handled = false; // 默认事件没有被处理
$event->name = $name; // 事件名称
foreach ($this->_events[$name] as $handler) {
$event->data = $handler[1];
// 最关键的地方:所有handler都是通过call_user_func来执行的
call_user_func($handler[0], $event);
// 如果在$handler[0]中,$event->handled被置为true,表示事件已经被处理好了,后续handler不用再执行了
if ($event->handled) {
return;
}
}
}
// 执行类级别的事件处理器
Event::trigger($this, $name, $event);
}
在触发事件时,我们经常会通过Event对象来传递数据:
假如有个场景是在文章下面评论送积分,那么评论后就会触发送积分的事件user_after_publish,另外我们知道送积分还有很多别的场合,不同场合送的分数不一样。因此我们积分需要有个类PointEvent来表示:
use yii\base\Event;
class PointEvent extends Event
{
//要赠送的积分数量
public $points = 0;
// 事件处理结果消息
public $msg = '';
// 其他方法
}
发表评论之前,先绑定“送积分”事件handler:
// 绑定handler
$user = Yii::$app->user->identity;
$user->on(User::EVENT_AFTER_PUBLISH, [$obj, 'afterPublish']);
....
// 在某个时间点触发
// 实例化一个PointEvent,points 指定为 10
$event = new PointEvent();
$event->points = 10;
$user->trigger(User::EVENT_AFTER_PUBLISH, $event);
事件处理器要为发表评论的用户积分+10:
public function afterPublish($event)
{
$user = $event->sender;
$points = $event->points;
$user->points += $points;
$user->save();
}
说到这里,可能有的小伙伴会问,用户发表评论获得积分这么个功能为啥要通过这种方式来实现,为啥不用下面“简单”的方式来实现呢:
public function publishComment()
{
$param = Yii::$app->request->post();
$user = Yii::$app->user->identity;
// 新建评论
$comment = new Comment();
$comment->load($param, 'data');
$comment->save();
// 更新用户积分
$user->points += intval($param['points']);
$user->save();
}
这样做,就是把新建评论和更新用户放在一个方法里面。但是这样做将会有个隐形的问题,如果用户评论之后,不光要积分+10,还要告知文章作者怎么办?这里只能在publishComment()后面继续添加代码了,如果哪天又要发送邮件啥的,还得继续往里面添加代码。这违反了“面对扩展开放,面对修改关闭”的编程原则,久而久之这块代码就会变得非常臃肿,很难再维护,分出去再写几个方法也无济于事。
分析这原因,就是从功能上说,评论和用户获得积分其实是松耦合的关系——你可以给积分也可以不给积分。但是在publishComment()方法你把这两个功能捆绑的死死的,丝毫分不开——这就是一种糟糕的设计。
相反,用事件就能很好解决这个问题。我们说,事件其实是一个流程上的某个特定的点,这里是流程就是用户发表评论,EVENT_AFTER_PUBLISH是发表成功后的一个节点,程序走到这里,触发一下。有处理器就执行,没有就继续往后执行。我们绑定了一个送积分的处理器 ,也可以绑定推送消息的处理器。这么看待问题,就已经解耦了两种功能。在实现上,将发表评论看做流程本身,而送积分,推送提醒看做是“附加”的,在需要的时候绑定下,不需要就不绑定。
下面是主流程:
public function publishComment()
{
$user = Yii::$app->user->identity;
// 新建之前的时间点:触发EVENT_BEFORE_PUBLISH
$user->trigger(User::EVENT_BEFORE_PUBLISH);
// 新建评论
$comment = new Comment();
$comment->load($param, 'data');
$comment->save();
// 新建之后的时间点:触发下 EVENT_AFTER_PUBLISH
$user->trigger(User::EVENT_AFTER_PUBLISH, $event);
}
有的场合是需要送积分:
$user->on(User::EVENT_AFTER_PUBLISH, [Points, 'givePoints']);
有的场合是要发邮件提醒:
$user->on(User::EVENT_AFTER_PUBLISH, [Email, 'notifyPoserOwner']);
还有的场合是需要判断用户有没有发表评论的权限:
$user->on(User::EVENT_BEFORE_PUBLISH, [Authorization, 'checkAuth']);
...
public function checkAuth($event)
{
$user = $event->sender;
if (!$user->isAdmin) {
throw new AccessDeniedException('你没有权限发表评论');
}
}
事件处理器Points::givePoints,Email::notifyPoserOwner,Authorization::checkAuth 分布在不同的类中,并没有出现在上面publishComment里面,而且可增可减,完全视需要而定。因此真正满足了“开闭原则”的要求。
小编心得:开闭原则——对扩展开放,对修改关闭。这是代码组织当中的一条非常重要的原则。
事件的级别
前面的事件,都是针对类的实例而言的,也就是事件的触发、处理全部都在实例范围内。这种级别的事件用情专一,不与类的其他实例发生关系,也不与其他类、其他实例发生关系。除了实例级别的事件外,还有类级别的事件。
这就好比是公司里的不同阶层。底层的码农们只能自己发发牢骚,个人的喜怒哀乐只发生在自己身上,影响不了其他人。而团队负责人如果心情不好,整个团队的所有成员今天都要战战兢兢,慎言慎行。到了公司老总那里,他今天不爽,那么公司所有员工都可能跟着遭殃。事件也是这样的,不同层次的事件,决定了他影响到的范围。
类级别的事件是由\yii\base\Event中的方法来实现的,和实例级别的事件在Component中的实现原理大同小异,只不过作用范围不同:
- 实例级别的事件只能影响自身
- 类级别的事件影响所有它的实例,类本身,所有子类,以及所有子类的实例
类级别事件
比如,我打算所有人发表评论后,都要发送给文章作者了。那么每个用户都去绑定一下那是多么糟糕的事情,那我们可以将发送提醒绑定在User类上,那么任何$user实例在发表评论后的节点上都绑定了发送提醒的处理器了。
如果某个场合又给某个实例$user
绑定了送积分的事件,那么等评论一发表,用户首先获得积分,然后收到邮件——实例级别的事件总是先触发,类级别的事件总是后触发。别的$user
没有绑定送积分的话当然就没有积分送了。
类级别事件handler的绑定通过Event::on()来实现的:
public static function on($class, $name, $handler, $data = null, $append = true)
{
$class = ltrim($class, '\\');
// 如果$append为true,那么$handler置于handler列表最后面
if ($append || empty(self::$_events[$name][$class])) {
self::$_events[$name][$class][] = [$handler, $data];
} else { // 如果$append为true,那么$handler置于handler列表最前面
array_unshift(self::$_events[$name][$class], [$handler, $data]);
}
}
相比Component::on(),Event::on()
还需要传入类(名) $class
。Event维护的$_event[]
要比Component下的$_event[]
多一个维度:$class。绑定和解绑事件handler其实相当于向$_events[$name][$class]
数组插入/删除handler的过程。当$append
为true,$handler
将被最后执行(默认情况),当为false,$handler
将被第一个执行,除非有后面的handler取代其位置。
Event::on(User::class, Comment::EVENT_AFTER_PUBLISH, [$this, 'afterPublish'], $data);
Event::on(User::class, Comment::EVENT_BEFORE_PUBLISH, [$this, 'beforePublish'], [], false);
类级别事件解绑通过Event::off(),和实例级别事件解绑过程类似:
public static function off($class, $name, $handler = null)
{
$class = ltrim($class, '\\');
if (empty(self::$_events[$name][$class])) {
return false;
}
if ($handler === null) {
unset(self::$_events[$name][$class]);
return true;
}
$removed = false;
foreach (self::$_events[$name][$class] as $i => $event) {
if ($event[0] === $handler) {
unset(self::$_events[$name][$class][$i]);
$removed = true;
}
}
// ...
}
如果传递参数class下事件handler,否则就将name的处理器清空。
事件的触发通过Event::trigger()来实现:
public static function trigger($class, $name, $event = null)
{
if (empty(self::$_events[$name])) {
return;
}
if ($event === null) {
$event = new static();
}
$event->handled = false;
$event->name = $name;
if (is_object($class)) {
// 当$class为一个对象时,sender默认便指定为这个对象
if ($event->sender === null) {
$event->sender = $class;
}
$class = get_class($class);
} else {
$class = ltrim($class, '\\');
}
// 将$class,$class所有的父类,$class所有实现的接口放入待检查的数组$classes
$classes = array_merge(
[$class],
class_parents($class, true),
class_implements($class, true)
);
foreach ($classes as $class) {
if (empty(self::$_events[$name][$class])) {
continue;
}
// 如果$classes中绑定有事件$name,那么就执行其名下所有handler
foreach (self::$_events[$name][$class] as $handler) {
$event->data = $handler[1];
// 类级别的事件handler最终也是通过call_user_func来执行,并传递事件$event
call_user_func($handler[0], $event);
if ($event->handled) {
return;
}
}
}
}
通过上面的源码和注释,可知类级别的事件可以向所有父类传递,子类事件handler执行,父类同名事件的handler也要执行。由于类级别事件会被类自身、类的实例、后代类、后代类实例所触发,所以,对于越底层的类而言,其类事件的影响范围就越大。因此,在使用类事件上要注意,尽可能往后代类安排,以控制好影响范围,尽可能不在基础类上安排类事件。
接口事件
还有一种更为抽象方式来处理事件,你可以为特殊的事件创建一个独立的接口, 然后在你需要的类中实现它。比如:
namespace app\interfaces;
interface DanceEventInterface
{
const EVENT_DANCE = 'dance';
}
然后在两个类中实现:
class Dog extends Component implements DanceEventInterface
{
public function meetBuddy()
{
echo "Woof!";
$this->trigger(DanceEventInterface::EVENT_DANCE);
}
}
class Developer extends Component implements DanceEventInterface
{
public function testsPassed()
{
echo "Yay!";
$this->trigger(DanceEventInterface::EVENT_DANCE);
}
}
要处理由这些类触发的 EVENT_DANCE ,调用 Event::on()来绑定,并将接口类名作为第一个参数:
你可以在这些类中触发这个事件:
// trigger event for Dog class
Event::trigger(Dog::class, DanceEventInterface::EVENT_DANCE);
// trigger event for Developer class
Event::trigger(Developer::class, DanceEventInterface::EVENT_DANCE);
其实这没有什么神秘的,看看Event::trigger()中有这么一段你就明白了:
$classes = array_merge(
[$class],
class_parents($class, true),
// $class 实现的接口事件也触发下
class_implements($class, true)
);
全局事件
全局事件本质上也是实例事件的一种,只不过是可以在任何地方进行绑定,解绑,触发。比如Application和Yii::$app所管理的任何组件。全局事件无非是因为这些实例是可全局访问的罢了。因为这些实例都是继承Component的,所以用法和Component的事件基本相同:
use app\components\Foo;
Yii::$app->on('beforeRequest', function ($event) {
echo get_class($event->sender); // 显示 "app\components\Foo"
});
Yii::$app->trigger('beforeRequest', new Event(['sender' => new Foo]));
推荐阅读
-
mysql事件之修改事件(ALTER EVENT)、禁用事件(DISABLE)、启用事件(ENABLE)、事件重命名及数据库事件迁移操作详解
-
Event事件对象之Event
-
ReactJS - 05 - ReactJS之入门之03之事件 Event 处理
-
Yii2中关于EVENT事件的实例详解
-
mysql事件之修改事件(ALTER EVENT)、禁用事件(DISABLE)、启用事件(ENABLE)、事件重命名及数据库事件迁移操作详解
-
Yii2的深入学习--事件Event
-
JavaScript加强之自定义event事件_javascript技巧
-
Yii2表单事件之Ajax提交实现方法
-
JavaScript加强之自定义event事件_javascript技巧
-
Yii2的深入学习--事件Event