Events & Listeners

Event-Driven Architecture

Events and listeners help decouple business logic and improve maintainability. Use events for actions like user registration, order placement, or notifications.

• Fire events from controllers, services, or models when important actions occur.
• Listen for events to trigger side effects (e.g., sending emails, logging activity).

Example:

// Fire an event
UserRegistered::dispatch($user);

Naming Conventions

• Name events using past tense (e.g., UserRegistered, OrderPlaced).
• Name listeners using action verbs (e.g., SendWelcomeEmail, LogOrderActivity).
• Use PascalCase for class names.

Organization

• Store events in app/Events.
• Store listeners in app/Listeners.
• Register events and listeners in EventServiceProvider.

Example:

// Event
class UserRegistered implements ShouldBroadcast {
    public $user;
    public function __construct(User $user) {
        $this->user = $user;
    }
}
// Listener
class SendWelcomeEmail {
    public function handle(UserRegistered $event) {
        Mail::to($event->user->email)->send(new WelcomeMail($event->user));
    }
}

Best Practices

• Use events for side effects, not for core business logic.
• Keep listeners focused and single-purpose.
• Document event and listener responsibilities with PHPDoc.
• Test event dispatching and listener behavior.

Example: Registering Events

// app/Providers/EventServiceProvider.php
protected $listen = [
    UserRegistered::class => [
        SendWelcomeEmail::class,
        LogUserRegistration::class,
    ],
];