Michael Korte – Senior Full-Stack Developer Freelancer aus Dortmund

Ziel dieses Teils

In Teil 1 haben wir MVC so betrachtet, wie man es kennt. In Teil 2 haben wir typische Bruchstellen gesehen.

Teil 3 zieht daraus Konsequenzen.
Noch ohne konkrete Technik – aber mit klaren Leitlinien, die später jede Entscheidung beeinflussen werden.

3.1 Wenn Disziplin allein nicht mehr skaliert

Viele der beobachteten Probleme lassen sich theoretisch vermeiden – durch sauberes Arbeiten, Reviews und Erfahrung.

• Regeln werden vergessen
• Abkürzungen schleichen sich ein
• „Nur dieses eine Mal“ wird zum Standard

Clean-Output-MVC geht davon aus, dass Menschen Fehler machen – und versucht, diese strukturell abzufangen.

3.2 HTML ist kein Nebenprodukt

In vielen Systemen entsteht HTML als Ergebnis von Logik. Das funktioniert – solange alles überschaubar bleibt.

• Semantik entsteht zufällig
• Meta-Informationen werden „nachgezogen“
• Accessibility wird geprüft, nicht gestaltet

3.3 Was „deterministisch“ hier bedeutet

„Deterministisch“ heißt in diesem Kontext nicht, dass es nur einen möglichen Weg gibt – sondern dass jeder Output eindeutig erklärbar ist.

• Ein Ergebnis hat eine nachvollziehbare Ursache
• HTML entsteht in einer definierten Phase
• Seiteneffekte sind sichtbar oder ausgeschlossen

In vielen klassischen MVC-Systemen kann HTML an mehreren Stellen entstehen:

• im Controller
• in Templates
• in Template-Extensions
• in Event-Listenern
• in Fehler-Handlern
• in Plugins

Das Ergebnis ist korrekt – aber die Herkunft oft schwer erklärbar.

3.4 Controller entscheiden – sie rendern nicht

Sobald Controller HTML erzeugen, verschwimmen Verantwortung und Darstellung.

• Controller treffen Entscheidungen
• Controller beschreiben Seitenzustand
• Controller erzeugen kein HTML

Rendering wird zu einer eigenen, klar abgegrenzten Phase – nicht zu einer beiläufigen Nebenwirkung.

3.5 Zustand statt Fragmente weiterreichen

Anstatt HTML-Fragmente oder Teil-Views zu erzeugen, beschreibt der Controller den Zustand einer Seite:

• Status-Code
• Meta-Informationen
• benötigte Assets
• strukturierte Inhaltsdaten

3.6 Kritische Frage: „Was, wenn Meta-Daten überschrieben werden?“

Eine berechtigte Sorge: Wenn Meta-Informationen veränderbar sind, muss man im Fehlerfall doch trotzdem suchen.

Clean-Output-MVC versucht nicht, Überschreibungen zu verbieten, sondern sie explizit und nachvollziehbar zu machen.

Wenn sich Meta-Daten ändern, dann:

• über einen bekannten Mechanismus
• in einem definierten Kontext
• als Teil des Seitenzustands – nicht als Seiteneffekt

3.7 Struktur vor Komfort

Viele Systeme setzen früh auf Komfort und versuchen Struktur später zu erzwingen.

Clean-Output-MVC dreht diese Reihenfolge bewusst um:

• erst Struktur
• dann klare Zuständigkeiten
• erst danach Komfort

Übergang zu Teil 4

Ab hier verlassen wir die reine Konzept-Ebene.

In Teil 4 bauen wir den Einstiegspunkt und das Bootstrap – bewusst explizit, ohne Magie, damit der Lebenszyklus sichtbar wird.