Was versteht man unter dem Problem der „Fat Controller“ in der Softwarearchitektur?

Melden

Das Problem des „Fat Controller“ (zu Deutsch: „fetter Controller“) ist ein bekanntes Anti-Pattern in der Softwarearchitektur, insbesondere innerhalb des MVC-Entwurfsmusters (Model-View-Controller).

Es beschreibt den Zustand, bei dem die Controller-Schicht einer Anwendung überladen ist, weil sie zu viele Aufgaben übernimmt, die eigentlich in andere Schichten gehören würden.

Hier ist eine detaillierte Aufschlüsselung des Problems:

1. Was genau passiert bei einem „Fat Controller“?

In einer sauberen MVC-Architektur sollte die Rollenverteilung wie folgt aussehen:

  • Model: Enthält die Geschäftslogik und die Datenstruktur.
  • View: Kümmert sich nur um die Darstellung (UI).
  • Controller: Fungiert lediglich als Vermittler. Er nimmt die Benutzereingaben entgegen, ruft das Model auf und wählt die passende View aus.

Ein Fat Controller entsteht, wenn der Entwickler beginnt, die Geschäftslogik direkt in den Controller zu schreiben. Der Controller enthält dann Code für:

  • Validierung von Daten.
  • Datenbankabfragen.
  • Komplexe Berechnungen.
  • E-Mail-Versand oder API-Aufrufe.
  • Formatierung von Daten für die View.

2. Warum ist das ein Problem?

Ein „fetter Controller“ führt zu mehreren negativen Konsequenzen für das Softwareprojekt:

  • Verletzung des Single Responsibility Principle (SRP): Der Controller hat plötzlich viele Gründe, sich zu ändern (wenn sich die Datenbank ändert, wenn sich die Geschäftslogik ändert, wenn sich das Routing ändert).
  • Schlechte Testbarkeit: Da die Logik fest mit dem HTTP-Request/Response-Zyklus des Controllers verdrahtet ist, lassen sich Unit-Tests nur schwer schreiben. Man muss oft die gesamte Umgebung (Requests, Sessions etc.) simulieren, um eine einfache Berechnung zu prüfen.
  • Mangelnde Wiederverwendbarkeit: Wenn die Logik im Controller feststeckt, kann sie nicht einfach an anderer Stelle (z. B. in einem CLI-Befehl oder einem anderen Teil der App) wiederverwendet werden.
  • Unübersichtlichkeit: Controller-Dateien wachsen auf hunderte oder tausende Zeilen an, was die Wartung extrem erschwert („Spaghetti-Code“).

3. Die Lösung: „Skinny Controller, Fat Model“ (oder Service Layer)

Um das Problem zu lösen, verfolgt man das Prinzip: „Thin Controller, Fat Model“.

  • Thin Controller: Der Controller sollte nur „koordinieren“. Er prüft grob die Eingabe, delegiert die Arbeit an einen Dienst (Service) oder das Model und gibt das Ergebnis zurück.
  • Service Layer: In modernen Architekturen (wie bei Spring Boot, Laravel oder NestJS) führt man eine zusätzliche Schicht ein. Die Geschäftslogik wandert in Service-Klassen.
  • Domain-Driven Design (DDD): Logik, die sich direkt auf Daten bezieht, wandert in die Entities (Models) selbst.

Beispiel (vereinfacht):

Schlecht (Fat Controller):

// Controller
public function createOrder(Request $request) {
    // 1. Validierung
    // 2. Lagerbestand prüfen (Datenbank-Logik)
    // 3. Preis berechnen
    // 4. Bestellung in DB speichern
    // 5. Bestätigungs-E-Mail senden
    // 6. View zurückgeben
}

Gut (Thin Controller):

// Controller
public function createOrder(Request $request) {
    $this->orderService->placeOrder($request->all());
    return view('success');
}

// OrderService
public function placeOrder($data) {
    // Hier passiert die eigentliche Logik (Validierung, DB, E-Mail)
}

Zusammenfassung

Das Problem des „Fat Controller“ ist ein Zeichen dafür, dass die Trennung der Zuständigkeiten (Separation of Concerns) vernachlässigt wurde. Die Lösung besteht darin, Geschäftslogik aus dem Controller in dedizierte Schichten (Models, Services, Use-Cases) auszulagern, damit der Controller nur noch als schlanke Schnittstelle zwischen Außenwelt und Anwendungslogik dient.