Let’s talk about how to use model events in Laravel

When working with Eloquent models, it is common to take advantage of events dispatched through the model lifecycle. There are a few different ways to do this, and in this tutorial I'll cover them and explain the pros and cons of each. [Related recommendations: laravel video tutorial]

I will use the same example for each method so that you can compare directly. This example assigns the model's UUID property to the UUID during creation of the model itself.

Our first approach uses the model's static bootstrap method to register the behavior. This allows us to work directly on the model and create it when the model is created .

declare(strict_types=1);

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Support\Str;

class Office extends Model
{
    public static function boot(): void
    {
        static::creating(fn (Model $model) =>
            $model->uuid = Str::uuid(),
        );
    }
}

This approach is great for small, direct reactions to model events, like adding UUIDs, because it's very easy to understand and you can see exactly what's happening on the model. The biggest problem with this approach is code duplication, if you have multiple models that need to be assigned UUIDs, you will be doing the same thing repeatedly.

This leads us nicely into the second approach, using a feature. In Laravel, if you create a method on a trait that starts with boot and ends with the trait name, your models can inherit the trait and automatically start them. Here is an example:

declare(strict_types=1);

namespace App\Models\Concerns;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Support\Str;

trait HasUuid
{
    public static function bootHasUuid(): void
    {
        static::creating(fn (Model $model) =>
            $model->uuid = Str::uuid(),
        );
    }
}

Using traits allows you to add this behavior to every model that requires it and is easy to implement. My biggest drawback is that stacking these behaviors can cause problems when multiple features want to take advantage of the same model event. They start fighting for priority and it quickly becomes a mess.

This leads us to the next option, model observers. A model observer is a class-based way to respond to model events, where the method corresponds to the specific event that was triggered.

declare(strict_types=1);

namespace App\Observers;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Support\Str;

class OfficeObserver
{
    public function creating(Model $model): void
    {
        $model->uuid = Str::uuid();
    }
}

This class needs to be registered somewhere, either with the service provider or the model itself (which is where I recommend it). Registering this observer in the model allows you to see the side effects of changing eloquent behavior at the model level. The problem with hiding it from the service provider is that it's hard to know unless everyone knows it exists. The biggest disadvantage of this approach is its visibility. In my opinion this method is great when used correctly.

Another way to solve this problem is to take advantage of the $dispatchesEvents property of the Eloquent model itself. This is a property on every Eloquent model that allows you to list events to listen to and the classes to call for those events.

declare(strict_types=1);

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Support\Str;

class Office extends Model
{
    protected $dispatchesEvents = [
        'creating' => SetModelUuid::class,
    ];
}

SetModelUuid will be instantiated during the life cycle of the Eloquent model, which is your opportunity to add behaviors and properties to the model.

declare(strict_types=1);

namespace App\Models\Events;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Support\Str;

class SetModelUuid
{
    public function __construct(Model $model)
    {
        $model->uuid = Str::uuid();
    }
}

This approach is one of the cleanest and easiest to understand because the model has a lot of visibility and you can easily share this class between models. The biggest question you'll face is whether you need to trigger multiple actions on model events.

Anyway, honestly, there is no right way to do this. You can choose any of the above methods and they will all work, but you should choose the method that works for you and your specific use case. I'd like to see more options for this specific feature.

For example, if you need to add multiple properties to a model on model events, observers are a good choice. However, is this the best option? What if we use the dispatch events attribute to run a custom pipeline for this model?

declare(strict_types=1);

namespace App\Models\Pipelines;

use App\Models\Office

class OfficeCreatingPipeline
{
    public function __construct(Office $model)
    {
        app(Pipeline::class)
            ->send($model)
            ->through([
                ApplyUuidProperty::class,
                TapCreatedBy::class,
            ]);
    }
}

As you can see, we can start using pipelines to add multiple behaviors for event modeling. Now, this hasn't been tested, so I don't know 100% if it's possible - but as a concept, it could open up a composable way to react to model events.

How do you handle model events in your Laravel project? Tell us on Twitter!

Original address: https://laravel-news.com/working-with-laravel-model-events

Translation address: https://learnku.com/laravel/ t/71183

For more programming related knowledge, please visit: Programming Video! !

The above is the detailed content of Let’s talk about how to use model events in Laravel. For more information, please follow other related articles on the PHP Chinese website!