Fette Controller in Laravel

In Laravel ist es sehr einfach, direkt im Controller mit der Lösung der Logik zu beginnen. Die Anfrage kommt dort an, das Framework erleichtert die Validierung, Abfrage von Modellen, die Rückgabe von JSON und das Auslösen von Prozessen. Für eine erste Version kann diese Geschwindigkeit nützlich sein.

Das Problem tritt auf, wenn dieses Muster zur Norm wird. Die Speichermethode beginnt mit der Validierung, entscheidet dann über Berechtigungen, fragt dann verschiedene Modelle ab, berechnet Gesamtbeträge, erstellt Datensätze, sendet Benachrichtigungen und erstellt eine manuelle Antwort. Der Controller ist kein Gateway mehr, sondern wird zum vollständigen Anwendungsfall.

Ein gesunder Controller koordiniert. Empfängt die Anfrage, delegiert die Validierung, Autorisierung und Ausführung und gibt eine Antwort zurück. Wenn Sie das gesamte Verhalten absorbieren, kann die Anwendung weiterhin funktionieren, aber jeder Endpunkt wird schwieriger zu lesen, zu testen und wiederzuverwenden.

Das offensichtlichste Zeichen sind mehrzeilige Speicher-, Aktualisierungs- oder Zerstörungsmethoden. Aber die Größe ist nicht der einzige Indikator. Es lohnt sich auch zu beobachten, ob innerhalb der Methode eine manuelle Validierung, komplexe Abfragen, mit HTTP gemischte Geschäftsbedingungen, wiederholte Autorisierungen oder handschriftliche Antworttransformationen vorliegen.

Ein weiteres häufiges Symptom besteht darin, dass E-Mail-Versand, Jobs, Benachrichtigungen oder Integrationen direkt vom Controller ausgeführt werden. Manchmal erscheinen auch generische Try/Catch-Methoden, die echte Fehler, doppelten Code zwischen Endpunkten oder inkonsistente Antworten verbergen, je nachdem, wer die einzelnen Methoden implementiert hat.

Wenn Sie zum Testen eines Geschäftsverhaltens eine vollständige Anfrage vorbereiten, den Benutzer authentifizieren, zu viele Abhängigkeiten einrichten und alles durchgehen müssen HTTP, hängt der Anwendungsfall wahrscheinlich zu sehr mit dem Controller zusammen.

Der Controller ist der erste sichtbare Punkt, wenn eine Anfrage eintrifft. In einem jungen Projekt erscheint die Lösung dort selbstverständlich: Sie ist griffbereit, schnell verstanden und erfordert keine Festlegung auf eine Struktur. Der Druck, Funktionen bereitzustellen, verstärkt diese Entscheidung, da das Erstellen einer Aktion oder eines Dienstes wie zusätzliche Arbeit erscheint.

Das Problem ist kumulativ. Eine isolierte Zeit kann nicht schaden. Zehn Regeln, verteilt auf mehrere Controller, ja. Wenn es keine klare Anwendungsschicht gibt, löst jeder Endpunkt letztendlich seine eigene Version des Prozesses. Dies führt zu Duplikaten, Inkonsistenzen und einer Architektur, die zu sehr von HTTP abhängt.

Laravel zwingt Sie nicht dazu, fette Controller zu schreiben. Es macht es einfach sehr billig, so anzufangen. Wenn die Anwendung bereits den Geschäftsbetrieb aufrechterhält, lohnt es sich daher zu prüfen, ob dieser anfängliche Komfort die Wartbarkeit beeinträchtigt.

Ein großer Controller erschwert die Wartung von Endpunkten. Das Ändern einer Regel kann sich auf Validierung, Persistenz, Reaktion, Benachrichtigungen und Berechtigungen in derselben Methode auswirken. Der kognitive Aufwand steigt, da der Leser viele Ebenen gleichzeitig verstehen muss.

Es treten auch fragilere Tests auf. Wenn das Verhalten innerhalb des Controllers vorhanden ist, ist es kompliziert, es zu testen, ohne HTTP durchlaufen zu müssen. Dies zwingt Sie dazu, sehr umfassende Funktionstests für Regeln zu schreiben, die direkter getestet werden könnten, wenn sie in einer Aktion oder einem Dienst wären.

Die Kopplung mit HTTP erschwert die Wiederverwendung von Logik in Befehlen, Jobs, internen Prozessen oder APIs-Alternativen. Eine kleine Änderung kann unerwartete Auswirkungen haben, da die Logik nicht isoliert ist. Mittelfristig ist Refactoring beängstigender als die weitere Anhäufung von Code.

Die erste Extraktion ist normalerweise eine Validierung. Mit Formularanfragen können Sie HTTP-Regeln aus der Methode entfernen und den Controller sauberer lassen. Die Autorisierung sollte auf Richtlinien oder Gates verschoben werden, wenn die Entscheidung wiederholt wird oder eine klare Zugangsregel darstellt.

Die Anwendungsfälle passen gut in Aktionen oder Dienste. Der Name und die Verantwortung spielen keine so große Rolle: Eine Klasse, die „Auftrag erstellen“, „Anfrage genehmigen“ oder „Client synchronisieren“ ausdrückt, ermöglicht es Ihnen, den Ablauf zu testen, ohne von HTTP abhängig zu sein. Antworten können an API-Ressourcen delegiert werden, um vereinzelte manuelle Transformationen zu vermeiden.

Asynchrone Prozesse, umfangreiche E-Mails oder Integrationen sollten an Jobs weitergeleitet werden, wenn dies sinnvoll ist. Ereignisse und Listener können helfen, Nebenwirkungen zu entkoppeln, sollten aber nicht als Versteck für Logik verwendet werden. DTOs oder Datenobjekte können nützlich sein, wenn das Projekt Daten klarer zwischen Ebenen übertragen muss.

Vorher: Eine Speichermethode validiert Felder, prüft Berechtigungen, erstellt mehrere Datensätze, berechnet Beträge, wendet Rabatte an, sendet eine E-Mail, löst eine Benachrichtigung aus, protokolliert Aktivitäten und gibt eine benutzerdefinierte Antwort zurück. Alles funktioniert, aber der Controller koordiniert nicht mehr: Er führt den gesamten Anwendungsfall aus.

Nachher: StoreOrderRequest wird validiert. OrderPolicy autorisiert. CreateOrderAction führt den Anwendungsfall aus. OrderResource transformiert die Ausgabe. Ein Job verwaltet schwere Aufgaben. Der Controller ist auf wenige Zeilen reduziert, die sich wie eine klare Abfolge lesen.

Der Vorteil ist praktisch. Wenn sich die Validierung ändert, wissen Sie, wo Sie tippen müssen. Wenn sich der Anwendungsfall ändert, versuchen Sie es ohne HTTP. Wenn sich die Antwort ändert, ändern Sie die Ressource. Wenn sich die Sendung ändert, überprüfen Sie den Auftrag. Jedes Stück hat weniger Gründe, sich zu ändern.

Ein Controller verdient eine Überprüfung, wenn er Methoden mit mehr als 40 oder 50 Zeilen, Geschäftsregeln, wiederholte Validierungen, komplexe Abfragen, direkte E-Mails oder Benachrichtigungen, manuelle Antworttransformationen oder doppelte Logik zwischen Endpunkten enthält.

Die nützliche Frage lautet nicht „Kann ich das verschieben?“, sondern „Wäre es klarer, wenn diese Entscheidung außerhalb von HTTP gelten würde?“ Wenn Sie den Anwendungsfall testen können, ohne eine vollständige Anfrage durchlaufen zu müssen, ist die Anwendung wahrscheinlich einfacher zu warten.

Ein großer Controller ist normalerweise ein frühes Anzeichen dafür, dass die Anwendung die Trennung der Verantwortlichkeiten verliert. Es ist nicht immer dringend, aber es ist ratsam, es zu erkennen, bevor jeder Endpunkt zu einem fragilen Teil wird.

Wenn Ihre Controller langsam wie vollständige Anwendungsfälle aussehen, kann Ihnen ein Backend-Audit Laravel dabei helfen, herauszufinden, welche Logik zuerst extrahiert werden sollte und welche Änderungen das größte Risiko reduzieren würden.