MVC – Model-View-Controller
Wenn eine Anwendung wächst, vermischt sich gerne alles in einem Klumpen: Datenbankzugriff steht im selben Code wie das HTML, das HTML wiederum prüft Geschäftsregeln, und der Button-Handler enthält SQL-Statements. Das funktioniert anfangs – wird aber irgendwann unwartbar. MVC (Model-View-Controller) ist ein Architekturmuster, das diese drei Aufgaben sauber trennt: das Model enthält Daten und Geschäftslogik, die View ist die Darstellung, der Controller nimmt Benutzereingaben entgegen und entscheidet, was zu tun ist. MVC ist nicht ein einzelnes Pattern wie Observer oder Strategy, sondern eine größere Strukturentscheidung – aber genau deswegen ist es prüfungsrelevant.
1) Die drei Rollen kurz erklärt
Bevor du den Datenfluss verstehen kannst, brauchst du die drei Akteure. Jeder hat eine klar abgegrenzte Aufgabe und darf nicht das tun, was dem anderen gehört:
- Model – die Daten und Geschäftslogik. Hält Zustand (z. B. Kundendaten, Bestelliste, Zähler) und kennt die Regeln (z. B. „Rabatt darf nicht negativ sein"). Weiß nichts von HTML, Buttons oder Bildschirmen.
- View – die Darstellung. Zeigt Daten aus dem Model an. Enthält keinerlei Geschäftslogik – sie ist „dumm" und ändert keine Daten selbst.
- Controller – der Vermittler. Nimmt Eingaben aus der View entgegen (Klick, Tastendruck, HTTP-Request), entscheidet, was zu tun ist, und ändert das Model. Anschließend wird die View aktualisiert.
2) MVC live – ein Klick fließt durchs System
Klick auf den „+1"-Button, um zu sehen, wie eine Aktion durch alle drei Schichten fließt. Du siehst, welche Komponente gerade aktiv ist und was sie tut. Beachte: das Model „weiß" nicht, dass es eine View gibt – die View beobachtet das Model (das ist intern Observer!):
3) Analogie: das Restaurant
Die einfachste Vorstellung: MVC ist wie ein Restaurant. Du als Gast siehst nur die Speisekarte und den Kellner – aber dahinter steckt eine ganze Kette:
Gast / Speisekarte
Was du siehst und worauf du klickst. Die Karte zeigt dir die Auswahl, du sagst „ich nehme Lasagne".
= ViewKellner
Nimmt deine Bestellung entgegen, schreibt sie auf, leitet sie an die Küche weiter. Macht selbst kein Essen.
= ControllerKüche
Kocht das Essen, kennt die Rezepte, hat den Vorrat. Sieht den Gast nie und weiß nicht, an welchem Tisch er sitzt.
= ModelDer Gast spricht nie direkt mit der Küche – der Kellner ist der Vermittler. Genau das macht den Code austauschbar: du kannst die Speisekarte (View) komplett anders gestalten – mobile App statt Papier – und die Küche bleibt unverändert.
4) Wo MVC dir begegnet
MVC ist seit den 1970ern (Smalltalk) Standard und steckt heute in fast jedem größeren Framework. Du musst es selten von Grund auf bauen – aber verstehen, wer welche Rolle einnimmt:
| Framework | Model | View | Controller |
|---|---|---|---|
| Spring (Java) | Service / Entity / Repository | Thymeleaf-Template / JSON | @Controller-Klasse |
| Django (Python) | models.py (ORM-Klasse) | Template (HTML) | views.py (heißt verwirrenderweise „view"!) |
| ASP.NET MVC | Klasse + DbContext | .cshtml-Razor-Seite | Controller-Klasse |
| Ruby on Rails | ActiveRecord-Model | .erb-Template | Controller-Aktion |
Bei Webanwendungen sieht die Aufteilung typisch so aus: ein HTTP-Request kommt rein → Routing leitet ihn an den Controller → Controller fragt das Model nach Daten oder ändert es → Controller wählt eine View aus → Template rendert HTML → Antwort geht zurück. Mehr zur Webseite des Ganzen siehst du in REST-Grundprinzipien.
5) MVC, MVP, MVVM – die Variantenfamilie
MVC ist alt, und in den 50 Jahren seit seiner Erfindung sind Varianten entstanden, die für bestimmte Plattformen besser passen. Drei wirst du in der Prüfung antreffen:
MVC
Klassisch. Controller koordiniert, Model benachrichtigt View direkt. View kennt das Model.
Webframeworks (Spring, Django)
MVP
Presenter statt Controller. Presenter holt Daten aus dem Model und gibt sie der View. View ist „dumm" und kennt nur den Presenter, nicht das Model.
Klassische Desktop-Apps (WinForms)
MVVM
ViewModel statt Controller. View bindet sich per Data Binding ans ViewModel. Änderungen am ViewModel propagieren automatisch (Observer-basiert).
WPF, Angular, Vue
Was alle drei gemeinsam haben: Trennung von Darstellung und Logik. Unterschied liegt darin, wie der Mittelteil organisiert ist und wer wen kennt. Für die Prüfung reicht meistens das klassische MVC – die anderen tauchen nur in Bonus-Fragen oder bei Webentwicklung-Aufgaben auf.
6) Vorteile und Stolperfallen
MVC ist nicht umsonst Standard, hat aber typische Fallen, in die Einsteiger gerne tappen:
| Vorteil | Stolperfalle |
|---|---|
| Klare Trennung von Zuständigkeiten (SoC) | „Fat Controller" – wenn Controller zu viel Logik tragen, statt sie ins Model zu schieben |
| UI und Daten austauschbar (Web + Mobile teilen Model) | „Anemic Model" – Models, die nur Daten halten, ohne Logik (alles steckt im Controller) |
| Mehrere Views auf dasselbe Model möglich | SQL oder HTML direkt im Controller statt im Model/Template |
| Bessere Testbarkeit (Model isoliert testbar) | View ruft direkt Model-Methoden zum Schreiben auf – das gehört in den Controller |
Faustregel: „Logik gehört ins Model, Routing in den Controller, Anzeige in die View." Wenn du in einer View ein if (kunde.bonität < 500) ... stehen siehst, ist das ein Code-Smell. Mehr zu sauberen Architektur-Prinzipien findest du in Anforderungen erheben und bei den SOLID-Prinzipien (insbesondere SRP – Single Responsibility).
7) Zusammenspiel mit anderen Mustern
MVC kommt selten allein – es ist eine Klammer, in der mehrere kleinere Patterns zusammenwirken:
- Observer für die View-Benachrichtigung: das Model „pingt" interessierte Views nach Änderungen. Siehe Observer-Muster.
- Repository als Schicht unter dem Model, um Datenbankzugriff zu kapseln. Siehe Repository-Muster.
- Strategy, wenn der Controller je nach Eingabe unterschiedliche Algorithmen wählt (z. B. Sortierung).
- Factory, um Model-Objekte zu erzeugen, ohne dass der Controller die konkrete Klasse kennen muss.
- Dependency Injection für die Verkabelung – Controller bekommt Model-Service injiziert. Siehe Dependency Injection.
Zusammenfassung
MVC (Model-View-Controller) ist ein Architekturmuster, das Anwendungen in drei Verantwortlichkeiten trennt: Model (Daten und Logik), View (Darstellung) und Controller (Vermittler für Eingaben). Datenfluss bei einer Benutzeraktion: View → Controller → Model → (per Observer) → View. Vorteile: klare Aufgabenteilung, austauschbare UI, bessere Testbarkeit. Stolperfallen: „Fat Controller" und „Anemic Model" – Logik gehört ins Model. Varianten: MVP (Presenter, View ist dumm) und MVVM (ViewModel mit Data Binding, typisch für Web-Frameworks). MVC ist kein einzelnes Pattern, sondern eine Klammer, in der häufig Observer, Repository und Strategy zusammenspielen.
Verwandte Lektionen: Observer · Repository · Dependency Injection · und mehrWeitere relevante LektionenStrategyFactorySOLID-PrinzipienREST-GrundprinzipienAnforderungen erhebenEvent-ListenerUnit-Tests aufbauen