Model View Controller

Grundidee und klassische Aufteilung

Model View Controller (MVC, englisch für Modell-Ansicht-Steuerung) ist ein Entwurfs- und Architekturmuster. Es teilt Software in Datenmodell (Model), Ansicht (View) und Programmsteuerung (Controller). Damit sollen Änderungen und Erweiterungen leichter werden; außerdem können Komponenten wiederverwendet werden. So kann etwa dasselbe Modell für Windows, Mac, Linux oder das Internet genutzt werden, während View und Controller jeweils neu umgesetzt werden.

Im klassischen Muster ist das Model unabhängig von View und Controller. Die View präsentiert Modelldaten und ermöglicht Benutzerinteraktionen, verarbeitet diese Daten aber nicht selbst. Der Controller verwaltet Model und View: Er erhält Interaktionen aus der View, wertet sie aus und veranlasst Änderungen an Darstellung und Daten. Ein Controller kann auch mehrere Modelle oder mehrere Ansichten verwalten.

Änderungen im Modell werden der Ansicht typischerweise mit dem Beobachter-Muster mitgeteilt. Auch Benutzerinteraktionen gelangen darüber von der Ansicht zum Controller. Die View verwendet oft das Kompositum-Muster, also eine Struktur, in der einzelne und zusammengesetzte Darstellungselemente einheitlich behandelt werden können.

Offene Zuständigkeiten im MVC

MVC legt nicht allgemein fest, wo Geschäftslogik, Validierung, Datenformatierung und Internationalisierung liegen müssen. Geschäftslogik sind Regeln und Funktionen zum Ändern der Daten. Sie wurde historisch oft im Controller programmiert, wird heute aber zunehmend im Modell umgesetzt. Dann enthält das Modell Geschäftsobjekte mit ihren Daten und Funktionen und kann isoliert, schnell, vollständig und automatisiert getestet werden. Manche MVC-Frameworks schreiben den Ort vor, andere überlassen ihn den Entwicklern.

Die Validierung von Benutzereingaben ist ebenfalls nicht fest zugeordnet. Einfache Formatvalidierungen können in der View erfolgen; Prüfungen, die stärker von der Geschäftslogik abhängen, eher im Modell oder Controller.

Auch Rohdatenformatierung und Internationalisierung können im Modell liegen. Das kann die Entwicklung der View vereinfachen, weil sie sich auf Widgets oder Templates beschränkt. Zugleich gelangen dadurch Darstellungsaspekte in das Modell, was der Trennungsidee widersprechen kann. Als Alternative können dafür eigene Funktionsbereiche vorgesehen werden, die weder Model, View noch Controller zugeordnet werden.

Moderne und webbasierte Varianten

Heute wird MVC auch für komplexere, feiner aufgeteilte und verschachtelte Systeme verwendet. Je nach Betrachtung kann ein Browser die View eines Gesamtsystems sein; zugleich kann ein einzelnes Formularelement im Browser selbst Modell, Darstellung und Steuerung enthalten. Die Trennung der drei Aufgaben bleibt die Grundidee. Begriffe wie Model-View-Presenter, Model-View-ViewModel und Model-View-Adapter beschreiben Varianten präziser.

Bei Desktop-GUIs vereinen Widgets wie Menüpunkte und Textfelder meist Darstellung und typische Controller-Aufgaben, besonders Event-Handling. Auswahllisten können ein internes Modell besitzen, das mit dem eigentlichen Modell synchronisiert werden muss. Filter und Bestätigungsdialoge lassen sich ebenfalls nicht eindeutig der klassischen Dreiteilung zuordnen. Der übergeordnete Controller überlässt daher Teile seiner früheren Aufgaben den Widgets und steuert vor allem das Modell sowie gegebenenfalls weitere View-Komponenten.

GUI-Frameworks liefern ausimplementierte Widgets, Schnittstellen für das zugrunde liegende Datenmodell sowie Schnittstellen und Klassen für Ereignisse durch Benutzerinteraktionen und Modelländerungen. Dadurch können etwa Datenspeicherung oder Aussehen ausgetauscht werden.

Bei Webanwendungen verteilt sich MVC im weiteren Sinn auf Browser und Server. Der Browser zeigt Inhalte an, nimmt Eingaben an und übernimmt allgemeine View- und Controller-Funktionen. Der Server steuert browserspezifische Abläufe über HTTP. Im engeren Sinn bezeichnet MVC oft nur das serverseitige Programm: Der Browser sendet bei Links oder Formularen einen HTTP-Request; der serverseitige Controller verarbeitet ihn und stößt die Erzeugung eines neuen Views an. Die HTML-Seite ist aus Browsersicht dessen Datenkern, aus Sicht des Gesamtsystems aber nur eine Sicht auf das serverseitige Gesamtmodell. Der serverseitige View erzeugt meist HTML per Template, dessen Platzhalter mit Modelldaten ersetzt werden.

JavaScript kann clientseitige Validierung oder Steuerungslogik zum Nachladen von Inhalten enthalten und seinerseits nach MVC strukturiert sein. Das ist von serverseitigem MVC zu unterscheiden, weil Client und Server getrennte Teilsysteme sind; solche Anwendungen werden häufig nach dem Single-Page-Paradigma umgesetzt. Bei einer AJAX-Anbindung bleibt insbesondere das Modell auf dem Server, während Teile des MVC-Programms und Widgets im Browser laufen.

Ablauf, Links und Benachrichtigungen im Web

Ein typischer serverseitiger Ablauf ohne HTTP-Redirect ist: Browser → HTTP-Request → Webserver → Controller. Der Controller kommuniziert beliebig oft mit Model oder View und liefert anschließend über den Webserver eine HTTP-Response an den Browser. Er kann nur Model und View zuordnen oder zusätzlich unter anderem Validierung, Internationalisierung, Geschäftslogik und Dateniteration übernehmen. Die konkrete Aufteilung hängt etwa von Programmiersprache, Framework, Webserver, Unit-Tests und Projektanforderungen ab.

Klassische Webanwendungen folgen einem Request-Response-Cycle: Der Browser kann auf Modelländerungen auf dem Server nicht unmittelbar reagieren, denn jede HTTP-Response setzt einen HTTP-Request voraus. Deshalb wurde das Beobachter-Muster typischerweise nicht eingesetzt; der Controller vermittelt aktiv zwischen Model und View. Server-Push kann das ändern: Long Polling verzögert die Antwort auf einen Request bis zu einem Ereignis, Websockets ermöglichen ebenfalls Übermittlungen vom Server ohne neue Anfrage. Damit kann das Beobachter-Muster in Webanwendungen eingeführt werden.

Hyperlinks und die Action-Adresse eines HTML-Formulars sind für Nutzer Controller-Elemente, enthalten aber als Ziel die Adresse einer neuen Ansicht. Die Funktionalität der URL muss deshalb bei der Seitenerzeugung von der reinen Ansicht getrennt werden. Eine ID kann im Controller mit einer Zieladresse verbunden werden; die View ruft die URL dann über eine Schnittstelle anhand der ID ab oder nutzt die ID als Platzhalter, etwa in Templates oder Link-Objekten.

Nach create oder update des Modells empfiehlt sich ein HTTP-Redirect. Nach erfolgreicher Validierung speichert die erste Anfrage den Datensatz, der Controller sendet einen Redirect, und die zweite Anfrage liest den nächsten Datensatz und zeigt ihn zur Bearbeitung an. Das verhindert mehrfaches Absenden bei einem Seitenreload und trennt Schreiben und anschließendes Lesen. Bei negativer Validierung entfällt der Redirect: Der empfangene Datensatz wird direkt im gleichen Formular zur Korrektur angezeigt, in der Regel ohne erneute Abfrage des Modells.

Für umfangreiche Websites werden Controller oft kaskadenartig organisiert. Eine häufige Dreiteilung lautet Front-Controller, Controller und Actions. Actions führen auf der untersten Ebene CRUD-Operationen aus: Create, Read, Update und Delete. Verschiedene MVC-Blöcke können gleichzeitig auf einer Seite vorkommen, etwa für einen zentralen Artikel und Kontextinformationen. Das Remote Presentation Model Muster trennt View und Controller stärker und erleichtert dadurch in vielen Bereichen die Auslagerung des Controllers auf den Server.

Beispiel einer Web-Registrierung

Bei einer einfachen Registrierung mit JavaServer Pages ruft der Client zuerst register.jsp auf und erhält ein HTML-Formular. Dessen Action ist validate.jsp. Nach dem Ausfüllen sendet der Browser die Eingaben an validate.jsp, das hier das Control-Modul ist.

validate.jsp prüft und verarbeitet die Werte, gibt aber selbst kein Feedback aus. Bei ungültigen Eingaben übergibt es die Kontrolle an register.jsp. Diese Seite zeigt das Formular erneut, zum Beispiel mit einem Fehlerhinweis; korrigierte Daten werden wieder an validate.jsp gesendet. Bei korrekten Daten werden sie zur Speicherung an die UsersBean übergeben. Anschließend erhält ok.jsp die Kontrolle und zeigt beispielsweise eine Erfolgsbestätigung.