您好,登錄后才能下訂單哦!
這篇文章將為大家詳細講解有關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\Listeners\DoSomething1', 'App\Listeners\Dosomething2', ],];
執行 artisan 命令,就可以自動在 app/Lisenter 目錄生成監聽器。
php artisan event:generate
這個命令也可以自動生成事件,如果沒有 UserLogin 這個事件會自動生成,而不需要手動生成。
可以看到 app/Listeners 目錄多了 DoSomething1.php 和 DoSomething2.php 兩個文件,我們看看其中一個內容:
<?php namespace App\Listeners; 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\\Listeners\\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 方法。
關于“Laravel中監聽事件和觀察者模式的使用示例”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,使各位可以學到更多知識,如果覺得文章不錯,請把它分享出去讓更多的人看到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。