Model View Controller

Model-View-Controller (MVC, wörtlich etwa „Modell-Präsentation-Steuerung“) bezeichnet ein Architekturmuster zur Aufteilung von Softwaresystemen in die drei Einheiten: Datenmodell (engl. Model), Präsentation (engl. View) und Programmsteuerung (engl. Controller).

Ziel des Modells ist ein flexibles Programmdesign, das u. a. eine spätere Änderung oder Erweiterung erleichtern und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglichen soll. Außerdem sorgt das Modell bei großen Anwendungen für eine gewisse Übersicht und Ordnung durch Reduzierung der Komplexität.

Eine Variante des MVC-Modells ist das MVC2-Modell. Es ist eine für Webanwendungen optimierte, zustandslose Variante des objektorientierten MVC-Modells.

Komponenten

Das MVC-Architekturmuster besteht aus drei Komponenten, die je nach Realisierung unterschiedlich stark voneinander abhängen:

Modell (model)

Das Modell enthält die darzustellenden Daten. Woher die Daten kommen und wie diese zusammenhängen, spielt keine Rolle. So kann es sich hierbei um ein Datenmodell, Geschäftsmodell oder sogar um ein für die Präsentation abstrahiertes Modell handeln. Das Modell kennt weder die Präsentation noch die Steuerung, weiß also gar nicht, ob und wie (oft) es dargestellt und verändert wird. Je nach Anwendung müssen jedoch Änderungen im Modell beobachtbar sein. Die Aspektorientierte Programmierung nutzt dies durch so genannte pointcuts (vgl. AspectJ) der Aspekte, die objektorientierte Programmierung in der Regel durch das Entwurfmuster „Beobachter“.

Präsentation (view)

Die Präsentation ist für die Darstellung der relevanten Daten aus dem Modell zuständig. Sie ist nicht für die Interaktion mit dem Benutzer verantwortlich (siehe Steuerung), sondern lediglich für die Beschaffung der Daten aus dem Modell, deren Darstellung und, bei Änderungen im Modell, der passenden Aktualisierung. Je nach Entwurf leitet sie auch Benutzeraktionen (oder: Events) an die Steuerung weiter.

Steuerung (controller)

Die Steuerung verwaltet die Sicht(en), nimmt von ihnen Benutzeraktionen entgegen, wertet diese aus und agiert entsprechend.

Anmerkungen

Das MVC-Architekturmuster trifft keine Aussage über die Positionierung der Geschäftslogik innerhalb der MVC-Klassen. Diese kann je nach Anwendungsfall besser im Steuerungsmodul (Control) aufgehoben sein oder besser in das Modell verlagert werden (z. B. wenn es mehrere solche Module gibt).
Auf Grund diverser Probleme bei der Realisierung in objektorientierter Programmierung, bedingt durch die Kapselung werden bei der Implementierung von Dialogen und Fenstern häufig die Steuerung und die Präsentation zusammengefasst. Das entstehende Modell wird Document-View-Modell genannt, in dem das Dokument dem MVC-Modell und die Präsentation (View) der Vereinigung von Steuerung und Präsentation (Control & View) entspricht.
Das Zusammenfassen von Steuerung und Präsentation ist problematisch, wenn zu einem Modell mehrere Präsentationen angezeigt werden, wie zum Beispiel die gleichzeitige Darstellung einer Tabelle als Text und als Kreisdiagramm. Hier sollte gewährleistet sein, dass eine Änderung des Modells sich anschließend in allen Präsentationen widerspiegelt. Der bessere Weg ist hier, dass die Steuerung nur das Modell ändert und dieses dann automatisch - gegebenenfalls erst nach einer Massenbearbeitung - alle Präsentationen nachführt, was am besten durch eine Trennung von Steuerung und Präsentation realisiert werden kann. In objektorientierten Umgebungen und in verteilten Netzen, kann die Steuerung gar nicht ohne weiteres ermitteln, wieviele und welche Präsentationen eines Modells gerade existieren und nachgeführt werden müssen.

Analyse

Üblicherweise spielen ein View- und ein Control-Modul zusammen, welche sich gegenseitig kennen und sich auf ein Modell beziehen. Ein Modell kann aber von mehreren View-Control-Paaren gesteuert werden. Beispielsweise kann ein Zahlenwert sowohl über ein Eingabefeld als auch über einen Schieberegler steuerbar sein. Ebenfalls ist denkbar, dass Datenmaterial aus dem Modell durch verschiedene Views dargestellt werden kann (z. B. in Form von Tabellen und Diagrammen). Verändert eines der dazugehörigen Control-Module den Wert, so sendet das Modell ein Ereignis (event), das dazu führt, dass sich beide grafischen Steuerelemente (controls) parallel aktualisieren.

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 (mit diversen Verfeinerungen und oftmals mehreren jeweils nach dem MVC-Muster aufgeteilten Modulen).

Die Bedeutung des MVC Entwurfmusters 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. Darüber hinaus muss die Kommunikation zwischen den einzelnen Komponenten in beide Richtungen gewährleistet sein. Zur Vermeidung von zirkularen Abhängigkeiten zwischen der Präsentation (view), dem Modell und der Programm-Steuerung (control) wird diese dann vorzugsweise mittels des Beobachter-Entwurfmuster realisiert, wofür die Infrastruktur von GUI-Frameworks mitgeliefert wird.

Das MVC Entwurfsmuster definiert damit den Rahmen für die Entwickler von GUI-Frameworks. Das fertige GUI-Framework beinhaltet:

eine Präsentation (view) in Form ausimplementierter GUI Widgets,
den Vertrag für das Modell in Form von Schnittstellen,
den Vertrag für Benachrichtigungen auf Grund von Benutzerinteraktionen in Form von Schnittstellen und ausimplementierten Klassen, sowie
den Vertrag für Benachrichtigungen auf Grund von Modelländerungen in Form von Schnittstellen und ausimplementierten Klassen.

Umstritten ist, ob es sich hierbei um ein Entwurfsmuster handelt. Nach strenger Auslegung ist das nicht der Fall, da es sich nicht um ein allgemeines, beliebig verwendbares Muster handelt, sondern um einen ganz konkreten Anwendungsfall, nämlich um den der Grafischen Benutzeroberfläche.

Beispiel

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.

Dies ist nur eine von vielen Möglichkeiten für ein MVC-Modell, sie zeigt jedoch die grundlegende Funktionsweise des MVC-Modells. An der Abbildung lässt sich außerdem gut erkennen, dass unproblematisch einzelne Teile, wie die Datenspeicherung oder das Aussehen, ausgetauscht werden können.

Durch den einfachen Austausch entsteht ein beachtlicher Vorteil des Modells. Die Anwendung kann mit neuer oder anderer Technologie an veränderte Anforderungen relativ einfach angepasst werden. Das MVC-Modell ermöglicht es also, eine anfangs „kleine“ Webanwendung im Nachhinein bei Bedarf mit mächtiger Technologie nachzurüsten.

Implementierungen

1979 wurde MVC das erste mal von Trygve Reenskaug beschrieben, der dann an Smalltalk beim PARC arbeitete. Diese ursprüngliche Implementierung inspirierte viele andere (GUI) Frameworks wie:

BlackBox Component Builder
Business Server Pages
CakePHP
Catalyst (Perl)
Cocoa
JavaServer Faces
Microsoft Foundation Classes (zweiteilig: CDocument steht für das Modell, und CView umfasst Präsentation und Steuerung)
NeXTSTEP/OPENSTEP und die darauf beruhenden Cocoa frameworks
Qt (Toolkit)
Ruby on Rails
Swing (Java)
Web Dynpro
wxWidgets
Symfony (PHP-Framework)

MVC 2

MVC 2 steht für MVC Version 2 bzw. MVC Model 2 und ist eine für Webanwendungen spezialisierte Variante des Architekturmusters Model-View-Controller (MVC, siehe oben).

Die Begriffe „Model 1“ und „Model 2“ stammen aus einem frühen Entwurf der JSP-Spezifikation. Unter Model 1 versteht man eine Architektur für Webanwendungen, bei der nur JSP-Seiten eingesetzt werden, welche HTTP-Requests direkt beantworten. Model 1 ist keine MVC-Architektur.

Im Gegensatz dazu ist Model 2 eine serverseitige Implementierung des MVC-Musters. Sie beschreibt insbesondere die Aufteilung der Anfragebearbeitung in eine Front-Komponente (Controller) und eine Präsentationskomponente (View). HTTP-Anfragen werden von einem Controller, meist einem Servlet, entgegengenommen und verarbeitet. Der Controller stellt aufgrund der Bearbeitung Beans (Model) im Session- oder Request-Kontext bereit und entscheidet, zu welcher Präsentationskomponente er intern weiterleitet. Die Präsentation wird üblicherweise von JSP-Seiten übernommen, die ihre Ausgabendaten aus den Beans beziehen.

Siehe auch

Literatur

Hanspeter Mössenböck, Objektorientierte Programmierung, Springer-Verlag, 1993, ISBN 3-540-55690-7

Weblinks

Trygve Reenskaug - MVC (englisch)
MVC (englisch)