现实场景
一个论坛系统，当后台管理人员进行删帖，需要对用户的发帖量进行重新计算。
所以，需要能监听 Model 的删除事件。
三种实现方法。后面两种为官方推荐的方法，然而我更喜欢第一种。。。
方法一
- 优点：简单粗暴
- 缺点：可读性不好。当你没看过 AppServiceProvider，并不知道还有这个触发的逻辑。
app/Providers/AppServiceProvider.php
public function boot()
{
Post::deleted(function($post){
$user_id = $post->user_id;
$post_count = Post::where([
['user_id', $user_id],
['status', 1],
])->count();
$user = User::find($user_id);
$user->post_count = $post_count;
$user->save();
});
}
方法二：标准的 Event 事件处理
- 优点：可读性最好。Model 中可以清楚地看到关系。
- 缺点：啰嗦。需要定义一个 Event，一个 Listener。
新建一个帖子删除对应的事件
php artisan make:event PostDeleted
运行命令之后，会发现多了一个文件
new file: app/Events/PostDeleted.php
这个也好麻烦，还需要实现一个 listener 。。。
Model 中再通过 events map 来指定对应逻辑。
方法三：Model 的 Observers
- 优点：集中处理 Model 的生命周期
- 缺点：可读性问题，同方法一。
参考：
https://laravel.com/docs/5.5/eloquent#observers
Observers 需要在 AppServiceProvider 中注册，所以当你没看过 AppServiceProvider ，单纯看 Model 的定义时，根本无法感知到这个 Model 还有一个对应的 Observers 。
而，标准的 Event 事件处理则可以通过 events map 来清楚的看到每个 model 事件对应的处理操作。
关于作者 🌱
我是来自山东烟台的一名开发者，有感兴趣的话题，或者软件开发需求，欢迎加微信 zhongwei 聊聊，或者关注我的个人公众号“大象工具”， 查看更多联系方式