米粒人生 2018-02-04 21:30:35 594次浏览 0条评论 0 2 0

说起事件(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 = [];

这里写图片描述

事件的绑定逻辑是这样的:

  • 参数 $append 是否为 true , 表示所要绑定的事件handler要放在 $_event[] 数组的最后面。这也是默认的绑定方式。
  • 参数 $append 是否为 false ,表示handler要放在数组的最前面。
  • 如果事件还没有绑定任何handler,那么无论$append为true还是false,$_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;
        }
    }
    // ...
}

如果传递参数$handler,那么解绑类$class下事件$name中的$handler,否则就将$class下的事件$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"
});

原文链接:http://blog.csdn.net/qq_24127857/article/details/79167689
Yii::$app->trigger('beforeRequest', new Event(['sender' => new Foo]));
gridvi tree treegrid
    没有找到数据。
您需要登录后才可以评论。登录 | 立即注册