Trennung der Zuständigkeiten

Was ist Model-View-Controller (MVC)?

MVC

Model-View-Controller ist ein Entwurfsmuster, das eine Anwendung in drei Zuständigkeiten teilt: das Model mit Daten und Fachlogik, die View für die Darstellung und den Controller, der eine Anfrage entgegennimmt und beide verbindet.

Spätestens wenn eine Anwendung neben der Weboberfläche auch eine Schnittstelle bekommt, zeigt sich, ob die Fachlogik jemals von der Darstellung getrennt war.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Drei Rollen: Model, View, Controller
Bekannt aus: Rails, Laravel, Spring MVC, ASP.NET MVC
Verwechselt mit: MVVM und Schichtenarchitektur
Warnzeichen: Controller mit mehreren hundert Zeilen

Was jeder Teil tut

Das Model hält die Daten und die Regeln, die für sie gelten, etwa dass eine Rechnung ohne Positionen nicht abgeschickt werden darf. Es weiß nichts von HTTP und nichts davon, ob das Ergebnis später als HTML oder als JSON hinausgeht.

Die View bekommt fertige Werte und macht daraus Ausgabe. In PHP-Frameworks ist das eine Template-Datei, etwa mit Blade oder Twig, die Schleifen und Bedingungen kennt, aber keine Datenbankabfragen.

Der Controller ist die dünnste Schicht. Er liest die Anfrage, prüft die Eingaben, ruft eine Methode im Model oder in einem Service auf und entscheidet, welche View oder welche Weiterleitung zurückgeht. Wenn ein Controller lang wird, ist das fast immer ein Zeichen, dass Fachlogik an der falschen Stelle liegt.

Wie Routing das zusammenhält

In Laravel und Symfony beginnt jede Anfrage beim Front Controller, einer einzigen Einstiegsdatei. Die Routing-Tabelle bildet Pfad und HTTP-Methode auf eine Controller-Aktion ab, aus /rechnungen/17 wird ein Aufruf mit dem Parameter 17.

Weil dieser Weg immer gleich ist, lassen sich Querschnittsthemen davorhängen: Authentifizierung, Sprache, Protokollierung. In Laravel heißt das Middleware, in Symfony sind es Events im Kernel. Beides sitzt zwischen Route und Controller, nicht im Controller.

Der übliche Fehler: der fette Controller

In vielen gewachsenen Projekten steht die Fachlogik im Controller, weil sie sich dort beim ersten Mal am schnellsten hinschreiben ließ. Sie ist damit an die Anfrage gebunden und lässt sich weder aus einem Cron-Skript noch aus einem Test heraus aufrufen, ohne eine HTTP-Anfrage nachzubauen.

Die Gegenbewegung ist, den Ablauf in eine eigene Klasse zu ziehen, oft Service oder Use Case genannt. Der Controller schrumpft dann auf drei Zeilen: Eingaben einsammeln, Dienst aufrufen, Antwort bauen. Diesen Dienst kannst du direkt testen und aus mehreren Einstiegspunkten benutzen.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Nicht verwechseln

Model-View-Controller und was oft damit gleichgesetzt wird

Model-View-Controller gegen Schichtenarchitektur

Die Schichtung trennt Darstellung, Fachlichkeit und Datenzugriff übereinander. MVC beschreibt nur die oberste Schicht genauer und sagt nichts darüber, wie du Repository und Datenbank organisierst.

Model-View-Controller gegen MVVM

Model-View-ViewModel stammt aus Oberflächen mit Datenbindung. Statt eines Controllers gibt es ein ViewModel, an dessen Eigenschaften die Ansicht direkt gebunden ist, Änderungen laufen automatisch in beide Richtungen.

Model-View-Controller gegen Front Controller

Der Front Controller ist die eine Einstiegsdatei, die alle Anfragen annimmt und weiterreicht. Er gehört zum Aufbau, ist aber nicht das C in MVC, denn dieses steht für die anwendungsspezifische Aktion.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

In der Praxis

Der Controller wächst, weil er der bequemste Ort für alles ist

Am Anfang steht eine Methode, die eine Anfrage entgegennimmt. Dann kommt die Berechtigungsprüfung dazu, danach die Preisberechnung, dann der Mailversand, und irgendwann liegt die halbe Fachlogik in einer Klasse, die eigentlich nur vermitteln sollte. Erkennbar ist der Zustand daran, dass sich diese Logik ohne eine echte HTTP-Anfrage nicht mehr testen lässt.

Der zweite typische Riss verläuft zwischen View und Model. Lädt ein Template selbst Daten nach oder rechnet Beträge zusammen, hängt die Darstellung an der Fachlogik. Sobald dieselbe Auswertung zusätzlich als Schnittstelle gebraucht wird, muss alles ein zweites Mal gebaut werden, und ab da driften beide Fassungen auseinander.

Was im Alltag hilft, ist eine Schicht, die das Muster gar nicht vorsieht: ein Dienst zwischen Controller und Model, der einen Anwendungsfall abbildet. Der Controller nimmt dann die Anfrage entgegen, übergibt an den Dienst und wählt nur noch die Antwortform, und die Fachlogik bleibt an einer Stelle, die du auch ohne Web-Framework aufrufen kannst.

Model-View-Controller lernen

Wie sich das in einem echten Framework anfühlt, vom Routing bis zum Template, arbeiten die PHP-Trainings für Webprojekte an einer durchgehenden Anwendung durch.

Die Gegenseite im Browser, also Zustand und Darstellung im Frontend, behandeln die Kurse zur Webentwicklung .

Kurse, die Model-View-Controller behandeln

Häufige Fragen

Gehört Validierung in den Controller oder ins Model?

Beides, aber Verschiedenes. Der Controller prüft die Form der Eingabe, also ob ein Datum ein Datum ist und Pflichtfelder da sind. Fachliche Regeln, etwa dass ein Urlaubsantrag nicht in der Vergangenheit liegen darf, gehören ins Model, damit sie auch beim Import gelten.

Braucht eine Schnittstelle mit JSON noch eine View?

Ja, nur heißt sie anders. Die Umwandlung eines Objekts in JSON ist Darstellung und gehört in eine eigene Klasse, in Laravel die API Resource, in Symfony der Serializer. So bleibt die Ausgabeform änderbar, ohne dass jemand am Model dreht.

Ist MVC bei einer Single-Page-Application noch relevant?

Auf dem Server ja. Der Browser übernimmt zwar die Darstellung, aber Routing, Controller-Aktion und Model bleiben auf der Serverseite bestehen, sie liefern nur JSON statt HTML.

Persönlich für dich da