𝗠𝗮𝘀𝘁𝗲𝗿𝗶𝗻𝗴 𝗘𝘃𝗲𝗻𝘁-𝗗𝗿𝗶𝘃𝗲𝗻 𝗗𝗲𝗰𝗼𝘂𝗽𝗹𝗶𝗻𝗴 𝗶𝗻 𝗟𝗮𝗿𝗮𝘃𝗲𝗹

Ihre Laravel-Controller werden oft zu Sammelbecken für Geschäftslogik.

Sie beginnen mit einem einfachen Registrierungsablauf. Schon bald fügen Sie E-Mail-Benachrichtigungen, Slack-Alerts, Audit-Logs und API-Aufrufe zu einer einzigen Methode hinzu. Dies führt zu einem „Fat Controller“.

Fat Controller machen Ihren Code fragil. Sie sind schwer zu testen. Sie verletzen das Single Responsibility Principle.

Sie benötigen keine komplexen Tools wie RabbitMQ, um dies zu beheben. Laravel verfügt über ein integriertes Event-System, das für die meisten Anforderungen ausreicht.

Das Problem bei enger Kopplung: Wenn eine Newsletter-API langsam ist, verlangsamt sich Ihre Benutzerregistrierung. Wenn ein Mail-Service ausfällt, schlägt die gesamte Anfrage fehl.

Die Lösung: Event-gesteuerte Architektur.

Events fungieren als Zwischenschicht. Ihr Controller kündigt eine Aktion an. Listener reagieren unabhängig auf diese Aktion.

Ein schlanker Controller sieht so aus:

public function register(RegisterRequest $request)
{
    $user = User::create($request->validated());

    UserRegistered::dispatch($user);

    return response()->json(['message' => 'Success'], 201);
}

Der Controller kümmert sich nun nur noch um die Datenpersistenz. Er ignoriert Seiteneffekte.

Sie gewinnen drei entscheidende Vorteile:

• Performance: Benutzer erhalten sofort eine Antwort. Schwere Aufgaben werden im Hintergrund mithilfe des ShouldQueue-Interfaces ausgeführt.
• Resilienz: Wenn ein Dienst offline ist, kann der Listener die Aufgabe wiederholen, ohne die Hauptanwendung zu beeinträchtigen.
• Erweiterbarkeit: Sie können neue Funktionen wie Push-Benachrichtigungen hinzufügen, indem Sie einen neuen Listener hinzufügen. Sie müssen den ursprünglichen Controller nicht ändern.

Best Practices, die Sie befolgen sollten:

• Fokus auf Seiteneffekte: Verwenden Sie Events für die Nachbearbeitung. Nutzen Sie sie nicht für die Kernlogik, die sofort ausgeführt werden muss.
• Verwenden Sie beschreibende Namen: Nutzen Sie Namen in der Vergangenheitsform wie OrderPlaced oder UserRegistered. Dies zeigt an, dass die Aktion bereits stattgefunden hat.
• Vermeiden Sie Über-Abstraktion: Wenn ein Codeabschnitt einfach ist und nur an einer Stelle verwendet wird, ist ein Funktionsaufruf besser als ein Event.

Verwenden Sie Eloquent Observers für Datenbankänderungen. Verwenden Sie Events für geschäftliche Aktionen.

Das Refactoring auf Events dient der Beständigkeit. Es macht Ihren Code einfacher zu debuggen und schneller zu testen.

Wählen Sie noch heute einen störenden Seiteneffekt in Ihrem Controller aus und verschieben Sie ihn in einen Listener.

Probieren Sie dieses Sandbox-Beispiel aus: https://onlinephp.io/c/1f7b2

Jenseits von Fat Controllers: Meistern der ereignisgesteuerten Entkopplung in Laravel

In der Welt der Laravel-Entwicklung kennen wir das alle: ein Controller, der so groß geworden ist, dass er schwer zu warten ist. Dies wird oft als „Fat Controller“ bezeichnet.

Das Problem: Fat Controllers

Ein Fat Controller ist ein Controller, der zu viele Verantwortlichkeiten übernimmt. Anstatt nur Anfragen zu routen und Antworten zurückzugeben, führt er Geschäftslogik aus, versendet E-Mails, aktualisiert mehrere Datenbanktabellen und vieles mehr.

Dies führt zu mehreren Problemen:

• Schwieriges Testen: Das Testen einer einzelnen Aktion wird aufgrund der vielen Seiteneffekte zum Albtraum.
• Geringe Wiederverwendbarkeit: Die Logik ist in einer spezifischen Controller-Methode gefangen.
• Schlechte Wartbarkeit: Wenn die Anwendung wächst, wird der Controller zu einem „God Object“.

Die Lösung: Ereignisgesteuerte Architektur

Die ereignisgesteuerte Architektur (Event-Driven Architecture, EDA) ist ein Entwurfsmuster, bei dem Komponenten durch das Auslösen und Abfangen von Ereignissen (Events) kommunizieren. Dies ermöglicht es uns, die Kernlogik von den Seiteneffekten zu entkoppeln.

Implementierung von Events und Listenern in Laravel

Laravel macht es unglaublich einfach, dieses Muster mithilfe von Events und Listenern zu implementieren.

1. Erstellen eines Events

Angenommen, wir haben ein UserRegistered-Event. Wir können es mit dem Artisan-Befehl erstellen:

php artisan make:event UserRegistered

2. Erstellen eines Listeners

Als Nächstes benötigen wir einen Listener, um zu verarbeiten, was passiert, wenn sich ein Benutzer registriert, wie zum Beispiel das Versenden einer Willkommens-E-Mail.

php artisan make:listener SendWelcomeEmail --event=UserRegistered

3. Auslösen (Dispatching) des Events

In unserem RegisterController versenden wir die E-Mail nicht direkt, sondern lösen einfach das Event aus:

public function store(Request $request)
{
    // ... Logik zur Benutzerregistrierung ...

    event(new UserRegistered($user));

    return redirect('/home');
}

Vorteile der Entkopplung

Durch die Verwendung von Events erreichen wir:

• Single-Responsibility-Prinzip: Der Controller kümmert sich nur um die Registrierung. Der Listener kümmert sich um die E-Mail.
• Skalierbarkeit: Wir können weitere Listener hinzufügen (z. B. NotifyAdmin, CreateProfile), ohne den Controller zu ändern.
• Testbarkeit: Wir können die Registrierungslogik und die E-Mail-Logik unabhängig voneinander testen.

Fazit

Der Schritt weg von Fat Controllers hin zu einem ereignisgesteuerten Ansatz macht Ihre Laravel-Anwendungen robuster, wartbarer und skalierbarer.