Wie funktionieren Events und Listeners?

Question

Accepted Answer

Laravel's **Events und Listeners** implementieren das Observer-Pattern — du **dispatcht ein Event**, wenn etwas Beachtenswertes passiert, und ein oder mehrere **Listeners** reagieren darauf. Dies entkoppelt Code: die Event-Quelle muss nicht wissen, wer antwortet, was eine saubere Trennung der Concerns ermöglicht.

## Defining an event and a listener

```php
// the event — a simple data carrier for "something happened"
class OrderShipped {
    public function __construct(public Order $order) {}
}

// a listener — reacts to the event
class SendShipmentNotification {
    public function handle(OrderShipped $event): void {
        Mail::to($event->order->customer)->send(new ShipmentMail($event->order));
    }
}
// generate with: php artisan make:event / make:listener
```

## Dispatching the event

```php
// when the order ships, DISPATCH the event — all listeners run
OrderShipped::dispatch($order);
// or: event(new OrderShipped($order));
```

Das Dispatchen des Events triggert alle registrierten Listeners. Der Order-Shipping-Code kündigt nur an, was passiert ist — er weiß nicht (und kümmert sich nicht darum), dass E-Mails, Analysen oder andere Reaktionen auftreten.

## Multiple listeners for one event (decoupling)

```php
// one event can have MANY listeners — each a separate concern
OrderShipped → SendShipmentNotification    // email
            → UpdateInventory               // adjust stock
            → RecordAnalytics               // log the event
// add reactions without modifying the order-shipping code
```

Dies ist der Schlüsselvorteil: Du kannst neue Reaktionen (einen Listener) zu einem Event hinzufügen, ohne den Code zu berühren, der es dispatcht — saubere, erweiterbare Entkopplung.

## Queued listeners (async)

```php
class SendShipmentNotification implements ShouldQueue {   // run the listener in the BACKGROUND
    public function handle(OrderShipped $event): void { ... }
}
```

Die Implementierung von `ShouldQueue` lässt einen Listener **asynchron** über die Queue laufen — damit langsame Reaktionen (E-Mail senden) die Response nicht verzögern.

## Warum es wichtig ist

Events und Listeners sind eine nützliche Laravel-Funktion zum **Entkoppeln** von Code — verschiedene Teile einer Anwendung können auf Ereignisse reagieren, ohne eng gekoppelt zu sein, was für Cross-Cutting-Reaktionen wertvoll ist und Code wartbar hält.

Sie zu verstehen ist hilfreich sowohl für ihre Nutzung als auch um sie in Codebasen zu erkennen: Das Pattern ermöglicht es dir, ein Event zu dispatchen, wenn etwas Bedeutsames passiert (eine Bestellung wird versendet, ein Benutzer registriert sich) und mehrere unabhängige Listeners zu haben, die reagieren (E-Mail senden, Bestand aktualisieren, Analysen aufzeichnen), jeder mit einer separaten Concern.

Der Schlüsselvorteil ist **Erweiterbarkeit durch Entkopplung** — du kannst neue Reaktionen hinzufügen, indem du einen Listener registrierst, ohne den Code zu ändern, der das Event dispatcht, was Concerns trennt und den Dispatching-Code fokussiert hält.

Die Möglichkeit, Listeners **queued** (`ShouldQueue`) zu machen, damit sie asynchron laufen, ist auch wichtig und ermöglicht es, langsame Reaktionen (E-Mails, externe API-Aufrufe) im Hintergrund auszuführen, ohne die Response des Benutzers zu verzögern.

Zu wissen, wie Events/Listeners funktionieren, ihr Entkopplung-Vorteil und Queued Listeners für asynchrone Verarbeitung ist wertvoll für den Aufbau gut strukturierter, erweiterbarer Laravel-Anwendungen. (Wie bei Signals in anderen Frameworks ist der Vorbehalt, dass Events implizites, Action-at-a-Distance-Verhalten erzeugen, das schwerer zu verfolgend ist — daher werden sie am besten für echte Cross-Cutting-Entkopplung verwendet, anstatt sie als Standard für alle Post-Action-Logik zu nutzen, wo expliziter Code oft klarer ist.)