Model-View-Controller (MVC) einfach erklärt

Große Programme werden schnell unübersichtlich. Model View Controller (MVC) teilt eine Software deshalb in drei Komponenten: Datenmodell, Ansicht und Programmsteuerung. Das ist ein Entwurfsmuster. Ein Entwurfsmuster ist eine bewährte Lösungsschablone für ein Problem, das beim Entwurf von Software immer wieder auftaucht. MVC kann sowohl als Architekturmuster als auch als Entwurfsmuster eingesetzt werden.

Ziel ist ein flexibler Programmentwurf. Eine spätere Änderung oder Erweiterung soll leichter werden, und die einzelnen Komponenten sollen sich wiederverwenden lassen.

Das Modell (englisch model) enthält die Daten, die von der Ansicht dargestellt werden. Es ist von Ansicht und Steuerung unabhängig. Die Ansicht (englisch view) stellt die Daten des Modells dar und setzt Benutzerinteraktionen um. Sie kennt das Modell, ist aber nicht für die Verarbeitung der Daten zuständig. Die Steuerung (englisch controller) verwaltet Ansicht und Modell. Sie wertet Benutzerinteraktionen aus und nimmt danach Anpassungen an der Ansicht und Änderungen an den Daten im Modell vor.

Wie stark die drei Komponenten voneinander abhängen, hängt von der Umsetzung ab. Ein Vorteil der Trennung: Es ist zum Beispiel möglich, dasselbe Modell für Windows, Mac, Linux oder für das Internet zu nutzen. Dann müssen nur Controller und View jeweils neu umgesetzt werden.

Im klassischen MVC arbeiten die Komponenten über das Beobachter-Muster zusammen. Es gibt Änderungen an einem Objekt an Strukturen weiter, die von diesem Objekt abhängen. Das beobachtete Objekt heißt Subjekt. Es hat eine Liste von Beobachtern, ohne deren konkrete Typen zu kennen. Es bietet eine Schnittstelle zum An- und Abmelden von Beobachtern und zum Benachrichtigen über Änderungen. Die Beobachter definieren eine Aktualisierungsschnittstelle.

Ein Beispiel: Messergebnisse werden gleichzeitig in einem Balkendiagramm, einem Liniendiagramm und einer Tabelle dargestellt. Die Messwerte ändern sich, und alle drei Darstellungen sollen die Änderung zeigen. Das gemessene Objekt soll dabei aber keine Kenntnis über die Struktur dieser Komponenten besitzen. Es kennt sie nur über die Beobachter-Schnittstelle. So können Subjekt und Beobachter unabhängig variiert werden.

Im MVC wird das Beobachter-Muster meist für das Zusammenspiel von Model und Views verwendet. Die Views sind die Beobachter des Models. Der Ablauf: Ein View kann den Controller veranlassen, etwas zu tun. Der Controller kann das Model aktualisieren. Das aktualisierte Model veranlasst seine Beobachter, also die Views, sich zu aktualisieren. Auch die Meldung von Benutzerinteraktionen an die Steuerung geschieht nach dem Beobachter-Muster.

Bei einer serverseitigen Webanwendung läuft es anders. Der Browser schickt einen HTTP-Request (eine Anfrage), wenn der Benutzer ein Formular absendet oder einen Link anklickt. Der Webserver übergibt ihn an die Anwendung. Der Controller verarbeitet die Daten des Requests und stößt die Erstellung eines neuen Views an. Serverseitig sind mit dem View die Programmteile gemeint, die den HTML-Code für die Antwort (Response) erzeugen. Häufig arbeitet der View mit HTML-Templates, deren Platzhalter mit den Daten des Models ersetzt werden. Der Controller arbeitet beliebig häufig mit Model oder View. Dann geht die HTTP-Response über den Webserver zurück an den Browser.

Das Beobachter-Muster kommt hier typischerweise nicht zum Einsatz. Jede Antwort an den Browser setzt eine Anfrage voraus (Request-Response-Cycle). Der Server kann den Browser bei klassischen Webanwendungen nicht von sich aus über Änderungen im Model informieren. Stattdessen tritt meist der Controller als aktiver Vermittler zwischen Model und View auf. Neuere Webanwendungen erlauben mit Server-Push, dass der Server Ereignisse direkt und ohne Anfrage an die Clients schickt.

Nach dem Ändern des Models (create oder update) empfiehlt sich ein HTTP-Redirect. Er verhindert, dass ein Seitenreload die Daten irrtümlich mehrfach absendet.

Bei einer Zuordnung fragst du nach der Verantwortung. Enthält die Komponente Daten? Dann passt sie zum Modell. Stellt sie Daten dar oder nimmt sie Eingaben des Benutzers entgegen? Dann passt sie zur Ansicht. Wertet sie Eingaben aus und ändert sie Daten oder Ansicht? Dann passt sie zur Steuerung. Begründe jede Zuordnung mit diesem Kriterium.

Im Aktienkurs-Beispiel sind der aktuelle Kurs das Modell und das Auswahlfeld sowie die Anzeige des Kurses die View. Der Programmteil, der mit dem Server spricht und den Kurs ins Modell schreibt, ist der Controller. In der Web-Registrierung unten übernimmt validate.jsp die Rolle des Controllers, register.jsp und ok.jsp sind Views. Die Daten gehen zur Speicherung an die UsersBean. Diese Aufgabe passt zum Modell, denn das Modell enthält die Daten.

Nicht jede Zuordnung ist eindeutig. Widgets sind die einzelnen Komponenten grafischer Benutzeroberflächen, zum Beispiel Menüpunkte oder Textfelder. Sie vereinen neben der Ansicht auch typische Merkmale des klassischen Controllers, etwa das Event-Handling. Das heißt: Sie reagieren selbst auf Ereignisse wie einen Klick. Man spricht trotzdem noch von einer Model-View-Controller-Architektur. Auch Filter zur Sortierung oder Bestätigungsdialoge lassen sich nicht eindeutig einordnen.

Für die Geschäftslogik gibt es keine allgemeingültige Vorgabe. Sie wird historisch bedingt oft noch im Controller programmiert, aber heute zunehmend im Modell. Liegt sie im Modell, kann dieses isoliert, schnell, vollständig und automatisiert getestet werden. Auch bei der Prüfung von Eingaben ist der Ort nicht festgelegt. Einfache Formatprüfungen können schon im View stehen. Prüfungen, die stärker die Geschäftslogik berücksichtigen müssen, werden eher im Modell oder in der Steuerung umgesetzt. Eine klare, eindeutige Trennung ist deshalb oft nicht möglich.

Die Rollen hängen außerdem von der Perspektive ab. Ein Webbrowser könnte als View eines größeren Gesamtsystems verstanden werden. Ein einzelnes Formularelement im Browser besteht wiederum aus einem kleinen Datenmodell, der zugehörigen Darstellung und seiner Steuerung.

Die Schichtenarchitektur ist ein häufig angewandtes Strukturierungsprinzip für die Architektur von Softwaresystemen. Einzelne Aspekte des Systems werden je einer Schicht zugeordnet. Die erlaubten Abhängigkeiten sind eingeschränkt: Aspekte einer höheren Schicht dürfen nur solche tieferer Schichten verwenden. Das verringert die Komplexität der Abhängigkeiten. Außerdem sind einzelne Schichten gut austauschbar, ohne das ganze System zu verändern.

Eine typische Drei-Schichten-Architektur hat eine Präsentationsschicht, eine Logikschicht und eine Datenhaltungsschicht. Bei einer Webanwendung wird die Präsentationsschicht im Webbrowser ausgeführt. Teile der Logikschicht und der Datenhaltung laufen serverseitig.

MVC teilt dagegen nach Daten, Darstellung und Steuerung. Allgemein kann die Schichtenarchitektur wesentlich grobgranularer entwickelt werden als MVC. Das heißt: Die Schichten sind größere Blöcke. MVC kann bei großer Software als Implementierung für eine Benutzeroberflächenschicht einer Mehrschichtenarchitektur verwendet werden. MVC ersetzt die Schichten also nicht, sondern kann die Oberflächenschicht umsetzen.

Ein Nutzen: Soll für eine bestehende Webanwendung eine alternative Benutzeroberfläche entstehen, zum Beispiel eine Mobile-Variante, braucht man eine weitere Benutzeroberflächenschicht. Geschäftslogik und Datenzugriffsschicht können aber weiterhin verwendet werden.

Die Einordnung von MVC selbst ist nicht ganz einheitlich: Es wird manchmal als Architekturmuster und manchmal als Entwurfsmuster eingesetzt.