Mit Google fortfahren
Model-View-Controller (MVC) einfach erklärt
Das Model-View-Controller-Muster (MVC) trennt den Zustand einer Anwendung, seine Darstellung und die Verarbeitung von Eingaben. Dadurch lassen sich Teile der Software leichter austauschen, testen und weiterentwickeln.
Auf dieser Seite lernst du das klassische MVC und die verbreitete Webvariante kennen. Du erfährst außerdem, warum die drei Rollen in realen Projekten nicht immer gleich zugeschnitten sind.
Hake ab, was du schon kannst — und komm am Ende hierher zurück!
Die drei Rollen trennen Verantwortlichkeiten
Stell dir eine Anwendung vor, mit der du Aufgaben verwaltest. Sie speichert Aufgabentexte und Erledigungszustände, zeigt eine Liste an und reagiert auf den Klick auf „Erledigt“. MVC verteilt diese Verantwortlichkeiten auf drei Rollen.
Model
Das Model verwaltet den darzustellenden Zustand, zum Beispiel Aufgaben und ihre Erledigungszustände. Es reagiert auf Abfragen und Änderungsaufforderungen. Je nach MVC-Variante kann es zusätzlich fachliche Logik enthalten oder weitere Fachkomponenten verwenden.
View
Die View stellt den Zustand für Menschen dar, zum Beispiel als Aufgabenliste. Sie soll sich auf die Darstellung konzentrieren und keine unnötige fachliche Logik übernehmen.
Controller
Der Controller verarbeitet Eingaben oder Requests und koordiniert die nächsten Schritte. Er kann eine Änderung am Model anstoßen und bestimmen, welche View angezeigt wird.
Eine lernende Person klickt bei „Referat vorbereiten“ auf „Erledigt“.
- Die View zeigt die Aufgabe und die Schaltfläche.
- Der Controller verarbeitet den Klick.
- Das Model ändert den Erledigungszustand.
- Die View zeigt danach den neuen Zustand an.
Der entscheidende Gedanke lautet: Die Darstellung speichert den fachlichen Zustand nicht selbst, und das Model entscheidet nicht über das Aussehen der Schaltfläche.
Frage bei der Zuordnung nach der Verantwortung: Zustand verwalten – darstellen – Eingaben und Ablauf steuern.
Klassisches MVC aktualisiert Views über Beobachter
Im ursprünglichen MVC verarbeitet der Controller technische Benutzereingaben und übermittelt die gewünschte Änderung an das Model. Die View liest den Zustand aus dem Model und stellt ihn dar.
Damit eine View eine Änderung bemerkt, kann das Beobachter-Muster eingesetzt werden. Eine View meldet sich beim Model als Beobachter an. Nach einer Zustandsänderung benachrichtigt das Model seine registrierten Beobachter, ohne deren konkrete Darstellung kennen zu müssen.
Eine Anwendung zeigt denselben Aufgabenbestand als Liste und als Fortschrittsanzeige.
- Beide Views melden sich beim Model an.
- Der Controller übermittelt die Aktion „Aufgabe erledigen“.
- Das Model ändert den Zustand.
- Das Model benachrichtigt beide Views.
- Jede View liest den neuen Zustand und aktualisiert ihre eigene Darstellung.
So kann eine neue Darstellung hinzukommen, ohne dass das Model ihren konkreten Aufbau kennen muss.
Im klassischen MVC können mehrere View-Controller-Paare dasselbe Model verwenden. Die Trennung bezieht sich auf Rollen und Instanzen. Sie verlangt nicht, dass für jede View eine völlig neue Controller-Klasse entwickelt wird.
Web-MVC folgt dem Request-Response-Ablauf
Bei einer serverseitigen Webanwendung beginnt der Ablauf meist mit einem HTTP-Request, also einer Anfrage des Browsers. Der Controller verarbeitet die Anfrage, arbeitet mit dem Model oder weiteren Fachkomponenten und wählt eine View. Die View erzeugt die Darstellung für die HTTP-Response.
Eine Person öffnet die Adresse einer bestimmten Aufgabe.
- Der Browser sendet einen Request.
- Das Routing leitet ihn an den passenden Controller weiter.
- Der Controller lässt die Aufgabe über das Model oder einen Service laden.
- Er übergibt die benötigten Daten an eine View.
- Die View erzeugt die Antwortseite.
- Der Browser stellt die Response dar.
Kurzform: Request → Controller → Model oder Service → View → Response.
Der Webcontroller übernimmt damit häufig mehr als der ursprüngliche Eingabe-Controller aus Smalltalk. Er kann Requests auswerten, Aktionen auswählen, Validierung koordinieren und die nächste View bestimmen.
Formulare nach erfolgreichem Speichern umleiten
Nach einer erfolgreichen Änderung wird häufig ein Redirect, also eine Umleitung, gesendet. Der Browser ruft daraufhin die Zielseite mit einem neuen Request ab. Das verhindert, dass ein erneutes Laden die vorherige Schreibanfrage versehentlich wiederholt.
Gültige Eingabe:
- Der Controller lässt die Eingabe prüfen.
- Das Model speichert die Änderung.
- Der Controller antwortet mit einem Redirect.
- Der Browser sendet einen neuen Lese-Request.
- Controller, Model und View erzeugen die aktuelle Seite.
Ungültige Eingabe:
Es wird nicht gespeichert und normalerweise nicht umgeleitet. Die View zeigt das Formular unmittelbar mit den bisherigen Eingaben und verständlichen Fehlermeldungen erneut an.
MVC ist keine eindeutige Gesamtarchitektur
MVC benennt drei Verantwortungsbereiche, legt aber nicht jede Einzelentscheidung fest. Vor allem die Begriffe Model und Controller werden in verschiedenen Varianten unterschiedlich weit verwendet.
| Frage | Enge klassische Sicht | Verbreitete Websicht |
|---|---|---|
| Was ist das Model? | Darstellbarer und veränderbarer Zustand | Häufig Daten plus Teile der Domänenlogik |
| Was macht der Controller? | Verarbeitet technische Eingaben | Verarbeitet Requests und koordiniert Abläufe |
| Wie wird die View aktualisiert? | Häufig durch Beobachter-Benachrichtigung | Meist durch eine neu erzeugte Response |
Domänenlogik
Domänenlogik sind die fachlichen Regeln eines Anwendungsgebiets, zum Beispiel die Regel, dass eine ausgeliehene Sache nicht gleichzeitig erneut ausgeliehen werden kann.
MVC schreibt nicht allgemeingültig vor, wo sämtliche Domänenlogik, Validierung, Formatierung oder Persistenz liegen muss. Frameworks und Projektentscheidungen präzisieren diese Aufteilung. In modernen Webprojekten bleiben Controller oft bewusst schlank und übergeben Facharbeit an Services oder Domänenmodelle.
MVC und Schichtenarchitektur unterscheiden
MVC ist nicht automatisch eine Drei-Schichten-Architektur.
- MVC trennt vor allem Zustand beziehungsweise Model, Darstellung und Interaktionssteuerung.
- Eine typische Schichtenarchitektur trennt Präsentation, Geschäftslogik und Datenzugriff.
Beide Strukturen können gemeinsam vorkommen. Ein MVC-Controller und eine View können beispielsweise zur Präsentationsschicht gehören, während das MVC-Model weitere Geschäfts- und Datenzugriffskomponenten verwendet.
„Model“ bedeutet nicht automatisch „die gesamte Geschäftslogik und Datenbank“. Prüfe immer, welche MVC-Variante und welche Systemebene gemeint sind.
Eine Architektur begründet zuordnen
Betrachte ein webbasiertes Ausleihsystem. Eine Person sendet ein Formular ab, um ein Gerät auszuleihen. Das System muss prüfen, ob das Gerät verfügbar ist, den Zustand ändern und anschließend die aktualisierte Geräteseite anzeigen.
Dein Architekturvorschlag
Ordne diese Aufgaben begründet zu:
- Formulardaten entgegennehmen
- Verfügbarkeit fachlich prüfen
- Ausleihzustand speichern
- Geräteseite darstellen
- nach erfolgreichem Speichern umleiten
- bei einem Fehler das Formular mit Eingaben und Fehlermeldung anzeigen
Überlege bei jeder Aufgabe zuerst: Geht es um Darstellung, fachlichen Zustand oder Ablaufsteuerung?
Musterlösung
- Der Controller nimmt die Formulardaten entgegen und koordiniert die Verarbeitung.
- Das Model oder eine vom Model verwendete Fachkomponente prüft die Verfügbarkeit. Die Regel betrifft den fachlichen Zustand und gehört nicht in die View.
- Das Model beziehungsweise eine zugehörige Persistenzkomponente speichert den neuen Ausleihzustand.
- Die View stellt die Geräteseite dar.
- Nach erfolgreichem Speichern veranlasst der Controller den Redirect.
- Bei einem Fehler wählt der Controller erneut die Formular-View und übergibt ihr Eingaben sowie Fehlermeldungen. Die View stellt beides dar.
Je nach Projekt kann die genaue Klassenaufteilung abweichen. Entscheidend ist, dass die fachliche Regel nicht in der Darstellung versteckt wird und der Controller nicht unnötig die gesamte Fachlogik übernimmt.
Karteikasten
Überlege zuerst selbst und drehe die Karte anschließend zum Prüfen um.
Alles auf einen Blick
- Model-View-Controller
- Model: Zustand und fachliche Änderungen
- View: Darstellung
- Controller: Eingaben und Koordination
- Klassisch: Beobachter aktualisieren Views
- Web: Request und Response
- Grenze: keine vollständige Schichtenarchitektur
- Nutzen: Austauschbarkeit, Testbarkeit und Wartbarkeit
Abschluss-Check
Prüfe jetzt, ob du die Rollen nicht nur benennen, sondern auch in neuen Situationen begründet anwenden kannst.
Du beherrschst den Kern, wenn du bei einer unbekannten Anwendung erklären kannst, wer den Zustand verwaltet, wer ihn darstellt und wer Eingaben oder Requests koordiniert – und wenn du begründen kannst, warum die genaue Klassenaufteilung je nach MVC-Variante abweichen darf.