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.
Nicht technisch im Detail – sondern konzeptionell:
Welche Regeln brauchen wir, damit diese Probleme gar nicht erst entstehen?
3.1 Wenn Disziplin allein nicht mehr skaliert
Viele der beobachteten Probleme lassen sich theoretisch vermeiden – durch sauberes Arbeiten, Reviews und Erfahrung.
Realität
Je größer ein Projekt oder ein Team wird, desto weniger verlässlich ist reine Disziplin als Schutzmechanismus.
- Regeln werden vergessen
- Abkürzungen schleichen sich ein
- „Nur dieses eine Mal“ wird zum Standard
3.2 Erste Konsequenz: HTML ist kein Nebenprodukt
Wenn Output-Qualität wichtig ist, darf HTML nicht zufällig entstehen.
- HTML ist das Produkt
- Rendering muss erklärbar sein
- Struktur muss vorhersehbar sein
Konsequenz
Es darf genau einen klaren Weg geben, auf dem HTML erzeugt wird.
3.3 Zweite Konsequenz: Controller dürfen nicht rendern
Wenn Controller gleichzeitig entscheiden und HTML erzeugen, verschwimmen Zuständigkeiten.
- Controller entscheiden
- Controller orchestrieren
- Controller rendern nicht
Rendering wird zu einer eigenen, klar definierten Phase.
3.4 Dritte Konsequenz: Zustand statt Logik weiterreichen
Statt HTML oder Fragmente zu erzeugen, sollte der Controller reinen Seitenzustand beschreiben.
- Status-Code
- Meta-Daten
- benötigte Assets
- strukturierte Inhaltsdaten
Wichtig
Der Controller beschreibt was eine Seite ist, nicht wie sie aussieht.
3.5 Vierte Konsequenz: Struktur vor Komfort
Viele Komfortfunktionen moderner Systeme entstehen früh – Struktur entsteht oft später.
Clean-Output-MVC dreht diese Reihenfolge bewusst um:
- erst Struktur
- dann klare Zuständigkeiten
- erst danach Komfort
Bewusste Entscheidung
Das System ist nicht dafür da, alles zu erlauben – sondern das Richtige naheliegend zu machen.
3.6 Das entstehende Leitmotiv
Aus diesen Konsequenzen entsteht eine klare Haltung:
- Deterministischer Ablauf
- Explizite Verantwortung
- Kein implizites Rendering
- Keine versteckten Abkürzungen
Das ist keine Optimierung von MVC.
Es ist ein bewusst enger Rahmen für sauberen Output.
Übergang zu Teil 4
Ab hier verlassen wir die konzeptionelle Ebene.
In Teil 4 bauen wir das erste Mal konkret: Einstiegspunkt, Bootstrap und eine minimale App – noch ohne Magie, aber mit klarer Struktur.