Laravel 事件系統用法的總結

這篇文章主要介紹了關於Laravel 事件系統用法的總結，有著一定的參考價值，現在分享給大家，有需要的朋友可以參考一下

Laravel 的事件提供了一個簡單的觀察者實現，能夠訂閱和監聽應用中發生的各種事件。事件類別儲存在 app/Events 目錄中，而這些事件的的監聽器則被儲存在 app/Listeners 目錄下。這些目錄只有當你使用 Artisan 命令來建置事件和監聽器時才會被自動建立。

事件機制是一種很好的應用解耦方式，因為一個事件可以擁有多個互不依賴的監聽器。例如，如果你希望每次訂單發貨時向使用者發送一個 Slack 通知。你可以簡單地發起一個 OrderShipped 事件，讓監聽器接收之後轉化成一個 Slack 通知，這樣你就可以不用把訂單的業務代碼跟 Slack 通知的代碼耦合在一起了。

產生一個事件類別

比如通過 artisan 命令產生一個 UserLogin 事件：

php artisan make:event UserLogin

在 app/Events 中就會自動產生一個 UserLogin.php 檔案，內容不多，如下：

<?php namespace App\Events; use Illuminate\Broadcasting\Channel;use Illuminate\Queue\SerializesModels;use Illuminate\Broadcasting\PrivateChannel;use Illuminate\Broadcasting\PresenceChannel;use Illuminate\Broadcasting\InteractsWithSockets;use Illuminate\Contracts\Broadcasting\ShouldBroadcast; class UserLogin{    use InteractsWithSockets, SerializesModels;     /**     * Create a new event instance.     *     * @return void     */    public function __construct()    {        //    }     /**     * Get the channels the event should broadcast on.     *     * @return Channel|array     */    public function broadcastOn()    {        return new PrivateChannel('channel-name');    }}

定義監聽器

一個事件可以被一個或多個監聽器監聽，也就是觀察者模式，我們可以定義多個監聽器，當這個事件發生，執行一系列邏輯。

在 EventServiceProvider 的 $listen 中可以定義事件和監聽器，如下：

protected $listen = [    'App\Events\UserLogin' => [        'App\Lisenter\DoSomething1',        'App\Lisenter\Dosomething2',    ],];

然後執行 artisan 命令，就可以自動在 app/Lisenter 目錄產生監聽器。

php artisan make:event generate

可以看到 app/Lisenter 目錄多了 DoSomething1.php 和 DoSomething2.php 兩個檔案，我們看看其中一個內容：

<?php namespace App\Lisenter; use App\Events\UserLogin;use Illuminate\Queue\InteractsWithQueue;use Illuminate\Contracts\Queue\ShouldQueue; class DoSomething1{    /**     * Create the event listener.     *     * @return void     */    public function __construct()    {        //    }     /**     * Handle the event.     *     * @param  UserLogin  $event     * @return void     */    public function handle(UserLogin $event)    {        info('do something1');    }}

在兩個監聽器的 handle 方法中我們列印一個日誌來測試一下，如代碼 handle 方法所示。

分發和觸發事件

我們在某個控制器的方法中來分發事件，也就是觸發事件，看監聽器是否正常工作。

就是一句話：

event(new UserLogin());

然後我們請求這個控制器，觀察日誌，發現列印了日誌：

[2018-06-17 10:04:29] local.INFO: do something1
[2018-06-17 10:04:29] local.INFO: do something2

那麼這個事件-監聽機制就正常工作了。

隊列非同步處理

如果某個監聽器需要執行的操作比較慢，可以放到訊息佇列進行非同步處理。

比如把上面的 DoSomething1 改成需要放入隊列的，只需要 implements ShoulQueue 介面。

class DoSomething1 implements ShouldQueue

也可以指定隊列驅動，如下代碼。

/**     * 任務應該發送到的隊列的串連的名稱     *     * @var string|null     */    public $connection = 'redis';     /**     * 任務應該發送到的隊列的名稱     *     * @var string|null     */    public $queue = 'listeners';

我們再次執行控制器方法。

日誌裡沒有列印 do something1，只有 do something2，但是在 redis 隊列裡發現了一個名為 queues:default 的列表。

{"job":"Illuminate\\Events\\CallQueuedHandler@call","data":{"class":"App\\Listener\\DoSomething1","method":"handle","data":"a:1:{i:0;O:20:\"App\\Events\\UserLogin\":1:{s:6:\"socket\";N;}}"},"id":"3D7VDUwueYGtUvsazicWsifwWQxnnLID","attempts":1}

這個時候需要使用 php artisan queue:work 執行隊列任務，才是真正執行 DoSomething1 這個監聽器的 handle 方法。

以上就是本文的全部內容，希望對大家的學習有所協助，更多相關內容請關注topic.alibabacloud.com！