Michael Korte – Senior Full-Stack Developer Freelancer aus Dortmund

Teil 2 – Grenzen von klassischem MVC

Nach Teil 1 ist klar: MVC ist kein Anti-Pattern. Es ist bewährt, verständlich und stabil. Und trotzdem erleben viele Entwickler irgendwann, dass es nicht mehr sauber skaliert, sobald HTML und Rendering komplexer werden.

In diesem Teil schauen wir uns die Grenzen an – nicht als Vorwurf, sondern als Grundlage: Wenn wir ein System bauen wollen, das Output konsequent kontrolliert, müssen wir wissen, wo MVC typischerweise anfängt zu rutschen.

2.1 MVC kennt keinen Output-Vertrag

Der klassische MVC-Ansatz sagt: „Die View rendert HTML.“ Aber er sagt nicht:

• wie genau dieser Output strukturiert sein muss
• wie konsistent Fehlerseiten, Statuscodes, Headers etc. sind
• wer entscheidet, was überhaupt als Output gelten darf

In vielen Projekten entsteht dann ein Problem: Output wird nicht „gebaut“, sondern entsteht.

2.2 Rendering wird oft zu einem Nebenschauplatz

In vielen MVC-Projekten wird Rendering als „letzter Schritt“ betrachtet:

• Controller holt Daten
• Controller wählt View
• View rendert

Das funktioniert gut – solange Rendering trivial ist. Sobald es aber um Dinge wie Layout-Strukturen, SEO-Optimierung, A11y und PageSpeed geht, wird Rendering plötzlich der teuerste Teil – und gleichzeitig am schlechtesten kontrollierte.

2.3 Controller wachsen über ihre Rolle hinaus

Der Controller ist im MVC das Bindeglied. In der Praxis wird er aber oft zu einem Sammelbecken:

• Query-Building
• Validierung
• Redirects
• Template-Entscheidungen
• Fehlerbehandlung
• Output-Details

Dadurch entsteht eine unschöne Dynamik: Der Controller wird nicht mehr Koordinator – sondern Renderer, Domain-Logic und Router in einem.

2.4 Fehlerseiten fühlen sich „anders“ an

Ein Klassiker: Fehlerseiten und Sonderfälle durchbrechen den normalen Rendering-Pfad. Plötzlich gelten andere Regeln:

• andere Templates
• andere Statuscodes
• andere Header
• andere Layouts

Das ist kein MVC-Fehler – sondern die Konsequenz, wenn Output kein zentraler Vertrag ist.

2.5 Erweiterbarkeit führt oft zu Unklarheit

Spätestens wenn Plugins, Module oder „Hooks“ ins Spiel kommen, kippt es häufig: Erweiterbarkeit wird mit „kann alles überall“ verwechselt.

Die Folge:

• Controller sind nicht mehr nachvollziehbar
• Templates werden indirekt verändert
• Routen tauchen auf, ohne dass klar ist woher
• Output ist nicht mehr stabil

Übergang zu Teil 3

In Teil 2 haben wir gesehen: MVC ist stabil – aber es schützt Output nicht. Der nächste Schritt ist daher nicht „MVC ersetzen“, sondern verstehen, wie Output Kontrolle verliert.