Model View Controller
Model-View-Controller (MVC, „Modell / Präsentation / Steuerung“) bezeichnet ein Architekturmuster zur Strukturierung von Software-Entwicklung in die drei Einheiten Datenmodell (engl. Model), Präsentation (engl. View) und Programmsteuerung (engl. Controller).

Ziel des Musters ist es, einen flexiblen Programmentwurf zu machen, der u. A. eine spätere Änderung oder Erweiterung erleichtert und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglicht.
Intro
Das MVC-Konzept wurde zunächst für Benutzungsoberflächen in Smalltalk durch Trygve Reenskaug beschrieben (Seeheim-Modell), gilt mittlerweile aber als De-facto-Standard für den Grobentwurf aller komplexen Softwaresysteme; teils mit Differenzierungen und oftmals mehreren jeweils nach dem MVC-Muster aufgeteilten Modulen.
Geschichte
Klassische Architektur
Die drei Komponenten hängen je nach Realisierung unterschiedlich stark voneinander ab:
Modell (model)
Das Modell enthält die darzustellenden Daten und gegebenenfalls (abhängig von der Implementation des MVC-Patterns) auch die Geschäftslogik.
Das Modell ist von Präsentation und Steuerung unabhängig. Die Bekanntgabe von Änderungen an relevanten Daten im Modell geschieht nach dem Entwurfsmuster „Beobachter“.
Präsentation (view)
Die Präsentationsschicht ist für die Darstellung der benötigten Daten aus dem Modell und die Entgegennahme von Benutzerinteraktionen zuständig. Sie kennt sowohl ihre Steuerung als auch das Modell, dessen Daten sie präsentiert, ist aber nicht für die Weiterverarbeitung der vom Benutzer übergebenen Daten zuständig. Im Regelfall wird die Präsentation über Änderungen von Daten im Modell unterrichtet und besorgt sich daraufhin die aktualisierten Daten. Die Präsentation verwendet das Entwurfsmuster „Kompositum“.
Steuerung (controller)
Die Steuerung verwaltet die Präsentation(en), nimmt von ihnen Benutzeraktionen entgegen, wertet diese aus und agiert entsprechend. Zu jeder Präsentation existiert ein Modell. Es ist nicht die Aufgabe der Steuerung, Daten zu manipulieren. Die Steuerung entscheidet aufgrund der Benutzeraktion in der Präsentation, welche Daten im Modell geändert werden müssen. Sie enthält weiterhin Mechanismen, um die Benutzerinteraktionen der Präsentation einzuschränken. Präsentation und Steuerung verwenden zusammen das Entwurfsmuster „Strategie“, wobei die Steuerung der Strategie entspricht.
Nicht exakt definierte Programmfunktionen
Da das MVC-Muster in verschiedenen Programmiersprachen unterschiedlich realisiert werden muss, gibt es selbst keine genaue Definition über die Positionierung der Geschäftslogik innerhalb der MVC-Klassen. Diese kann je nach Anwendungsfall besser im Controller aufgehoben sein oder auch in das Modell verlagert werden. In der Praxis finden sich unterschiedliche MVC-Programmiergerüste: Einige schreiben strikt vor, wohin die Geschäftslogik gehört, andere überlassen diese Entscheidung dem Softwareentwickler.
In ähnlicher Weise ist der Ort für die Validierung der Benutzereingaben nicht definiert. Einfache Formatvalidierungen können bereits im View realisiert werden. Validierungen, welche stärker die Geschäftslogik berücksichtigen müssen, werden eher im Model oder im Controller implementiert.
Heutige Umsetzungen
Heutige Umsetzungen halten sich in der Regel nicht so streng an die drei Komponenten Model, View und Kontroller. Obwohl sich viele Projekte als Model-View-Controller-Architektur definieren, wird der Begriff sehr verschieden interpretiert. Es etablieren sich neue Begriffe, wie das Model View Presenter Muster oder das Model-View-Adapter-Muster, die versuchen die Varianten präziser zu beschreiben.
Widget Bibliotheken für Desktop-Applikationen
Als Widgets werden die einzelnen Komponenten grafischer Oberflächen bezeichnet, wie Menüpunkte oder Editor-Komponenten.
Widgets zeichnen sich dadurch aus, daß sie neben der Präsentation auch typische Merkmale des klassischen Controllers in einer Komponente vereinen, wie das Event-Handling. Einige Widgets, wie z.B Auswahllisten, können sogar über ein eigenes internes Model verfügen, wobei dieses dann mit dem eigentlichen Model synchronisiert werden muß.
Obwohl die Wigets die feste Dreiteilung durchbrechen, spricht man trotzdem noch von einer Model-View-Controller Architektur. Es kommen auch Komponenten wie Sortierfilter oder Bestätigungsdialoge, die sich nicht eindeutig in die klassische Dreiteilung einordnen lassen.
Bei der Anwendung der Widget Bibliotheken überläßt der Controller damit einen Teil der klassischen Controller-Funktion den Widgets und beschränkt sich auf die Steuerung des Models und ggf. anderer Komponenten des Views.
Webanwendungen
Bei Webanwendungen findet die eigentliche Präsenstation und die Auswertung der Usereingaben clientseitig durch den Browser statt. Der Browser ist über das HTTP-Protokol mit dem Server verbunden.
Serverseitige Webanwendungen
Unter dem View werden die serverseitigen Programmteile verstanden, die den HTML-Code erzeugen. Der Controller wertet serverseitig die eintreffenden Daten des Browsers aus.
Bei Webanwendungen kann der Browser nicht ohne Aktivität des Controllers auf Update-Signale des Models reagieren. Ohne aktive Anforderung des Benutzers können nämlich keine neuen Daten an den Browser gesendet werden. Daher ist das Observermuster hier zwar grundsätzlich möglich, aber weniger sinnvoll. Stattdessen wird das Model (oder Rückgabedaten des Models) typischerweise bei jeder Anforderung durch den Controller aktiv an den View weitergereicht. Oft veranlaßt der Controller auch das Verschicken der neu erzeugten HTML-Seite. Hier übernimmt der Controller zusätzliche Funktion.
Webanwendungen mit JavaScript-Bibliotheken und AJAX-Anbindung
Hier wird ein Teil der Programme der Model-View-Controller Architektur clientseitig im Browser eingesetzt, während ein anderer Teil, insbesondere das Model, auf dem Server verbleibt. JavaScript-Bibliotheken stellen vielfältige Widgets zur Verfügung. Diese Anwendungen nehmen eine Zwischenstellung zwischen Webanwendungen und desktopartigen Widget-Bibliotheken ein.
Beispiele

Die obige Abbildung zeigt das MVC-Modell für eine einfache Web-Registrierung. Der Benutzer (Client) fragt als erstes die Seite register.jsp an. Er bekommt eine Seite mit einem HTML-Formular als Antwort. Als Action ist im Formular die validate.jsp angegeben. Also schickt der Browser nach dem Ausfüllen des Formulars die eingegebenen Daten an die validate.jsp. Validate.jsp, welches in diesem Fall das Control-Modul ist, prüft die eingegebenen Werte. Es ist nur für die Prüfung und Verarbeitung der Daten zuständig. Selbst gibt validate.jsp dem Benutzer kein Feedback. Das Control-Modul gibt dazu die Kontrolle an die entsprechenden Views weiter. In diesem Fall entweder an register.jsp, wenn die Eingaben ungültig waren, sonst an die ok.jsp. Wird die Kontrolle wieder zurück an die register.jsp übergeben, zeigt register.jsp dem User erneut das Formular mit z. B. einem Fehler-Hinweis an. Der Browser schickt die korrigierten Daten wieder an die validate.jsp. Sind die Eingaben korrekt, werden die Daten zur Speicherung an die UsersBean übergeben. Die Kontrolle wird daraufhin an die ok.jsp abgegeben. Diese zeigt dem User beispielsweise eine Erfolgsbestätigung.
Die Bedeutung des MVC-Entwurfsmusters wird noch klarer, wenn man sich in die Lage der Entwickler von GUI-Frameworks versetzt. Hier besteht die Herausforderung darin, dass zum Entwicklungszeitpunkt der GUI Widgets (View) nicht feststeht, welche fachliche Daten und Datenstrukturen (Modell) repräsentiert und welche fachlichen Abläufe (Control) realisiert werden sollen. Damit besteht die Aufgabe der Entwickler eines GUI-Frameworks auch darin, eine Abstraktion für das Modell in Form von Schnittstellen bereitzustellen. An der Abbildung lässt sich gut erkennen, dass einzelne Teile, wie die Datenspeicherung oder das Aussehen, problemlos ausgetauscht werden können.
Das MVC-Entwurfsmuster definiert auch den Rahmen für die Entwickler von GUI-Frameworks. Ein fertiges GUI-Framework beinhaltet:
- eine Präsentation (view) in Form ausimplementierter GUI Widgets,
- die Vereinbarung eines zugrundeliegenden Datenmodells in Form von Schnittstellen,
- die Vereinbarung von Ereignissen (engl. events) auf Grund von Benutzerinteraktionen in Form von Schnittstellen und ausimplementierten Klassen, sowie
- die Vereinbarung von Ereignissen auf Grund von Modelländerungen in Form von Schnittstellen und ausimplementierten Klassen.
Implementierungen
Die ursprüngliche MVC Implementierung inspirierte viele andere (GUI) Frameworks wie:
- BlackBox Component Builder
- Business Server Pages
- CakePHP
- Catalyst (Perl)
- Cocoa
- Django & Pylons (Python-Frameworks)
- GTK+
- JavaServer Faces
- Microsoft Foundation Classes (dort jedoch nur zweiteilig: CDocument steht für das Modell, und CView umfasst Präsentation und Steuerung)
- NeXTSTEP/OPENSTEP und die darauf beruhenden Cocoa frameworks
- Qt
- Ruby on Rails
- Struts
- Web Dynpro
- WebObjects
- wxWidgets
- Symfony (PHP-Framework)
- Zend Framework (PHP-Framework)
- Zikula
Siehe auch
- Ajax (Programmierung)
- Struts
- Servlet
- JavaServer Pages
- Schichtenarchitektur
- Aspektorientierte Programmierung (AOP)
- Objektorientierte Programmierung (OOP)
Literatur
- Hanspeter Mössenböck, Objektorientierte Programmierung, Springer-Verlag, 1993, ISBN 3-540-55690-7
Weblinks
- Trygve Reenskaug - MVC (englisch)
- Portland Pattern Repository - Model View Controller (englisch)