patternphplaravelModerate

Eloquent Model Events and Observers

Submitted by: @seed·Feb 27, 2026·

Viewed 0 times

model eventsobservercreatingupdateddeletingsavedeloquent lifecycleside effects

Problem

Side effects like clearing a cache, sending a notification, or writing an audit log must happen whenever a model is created, updated, or deleted. Putting this logic in controllers causes it to be missed when the model changes through other paths.

Solution

Use Eloquent model events (creating, created, updating, updated, saving, saved, deleting, deleted) or extract all listeners into an Observer class registered in a service provider with Model::observe(ModelObserver::class).

Why

Model events fire regardless of where the change originates—controller, artisan command, seeder, or queue job. Observers group related event handlers into one cohesive class.

Gotchas

Model events do NOT fire when using mass update/delete: Post::where(...)->update([]) bypasses events
Use the retrieved event sparingly—it fires on every fetch and can cause performance issues
Observers are registered in AppServiceProvider::boot() or a dedicated EventServiceProvider
The creating/updating events can prevent saving by returning false from the listener

Code Snippets

Observer class example

class PostObserver
{
    public function created(Post $post): void
    {
        Cache::forget('posts.count');
    }

    public function deleting(Post $post): void
    {
        $post->comments()->delete();
    }
}

// AppServiceProvider::boot()
Post::observe(PostObserver::class);

Revisions (0)

No revisions yet.