Wikipedia

Model View Controller

Muster zur Unterteilung einer Software in die drei Komponenten Datenmodell, Präsentation und Programmsteuerung
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 18. Mai 2006 um 10:55 Uhr durch Stern (Diskussion | Beiträge) (→Model). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Der Begriff Modell-Präsentation-Steuerung (MPS) bzw. englisch Model-View-Controller (MVC) 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, um u.a. eine spätere Änderung oder Erweiterung einfach zu halten und die Wiederverwendbarkeit der einzelnen Komponenten zu ermöglichen. Außerdem sorgt das Modell bei großen Anwendungen für eine gewisse Übersicht und Ordnung durch Reduzierung der Komplexität. Gleichzeitig bringt die Trennung auch eine Rollenverteilung mit sich. Fachkräfte können so optimal, ihrer Fähigkeit entsprechend, eingesetzt werden:

  • Controller - Der Programmierer erstellt die nötige Geschäftslogik (implementiert Algorithmen, stellt fertig aufbereitete Daten bereit, etc.)
  • View - Ein Gestalter oder GUI-Designer erstellt das grafische Erscheinungsbild
  • Modell - Datenbankexperten kümmern sich um die optimale Datenverwaltung, Datenbankdesign usw.


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

Schichten

Modell (model)

Das Datenmodell enthält die dauerhaften (persistenten) Daten der Anwendung. Das Model hat lesenden Zugriff auf diverse Backend-Speicher wie zum Beispiel Datenbanken. Das Model kennt weder die View noch den Controller, es weiß also gar nicht, wie, ob und wie oft es dargestellt und verändert wird. Änderungen im Model werden allerdings über einen Update-Mechanismus bekannt gegeben, indem ein Event ausgelöst wird. Dazu muß sich zumindest die View als abhängiges Objekt am Model registrieren, um über Datenänderungen informiert zu werden (Vergleiche Beobachter (Entwurfsmuster)).

View

Die Darstellungsschicht präsentiert die Daten in der Regel - jedoch nicht notwendigerweise - zwecks Anzeige. Die Programmlogik sollte aus dem View entfernt werden. Der View kennt das Model und ist dort registriert, um sich selbständig aktualisieren zu können.

Controller

Der Controller verwaltet die Sichten, nimmt von ihnen Benutzeraktionen entgegen, wertet diese aus und hat schreibenden Zugriff auf das Modell. Er enthält die Intelligenz und steuert den Ablauf (engl. Workflow) der Anwendung.

Das MVC-Muster trifft keine Aussage über die Positionierung der Geschäftslogik innerhalb der MVC-Klassen. Diese kann je nach Anwendungsfall besser im Controller aufgehoben sein oder besser in das Modell verlagert werden (z.B. wenn es mehrere Controller gibt).

Analyse

Üblicherweise spielen eine View und ein Controller zusammen, welche sich gegenseitig kennen und sich auf ein Model beziehen. Ein Model kann aber von mehreren View-Controller-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 Model durch verschiedene Views dargestellt werden kann (z.B. in Form von Tabellen und Diagrammen). Verändert einer der dazugehörigen Controller den Wert, so sendet das Model einen Event, der dazu führt, dass sich beide grafischen 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 defacto Standard für den Grobentwurf aller komplexen Softwaresysteme (mit diversen Verfeinerungen und oftmals mehreren jeweils nach MVC pattern aufgeteilten Modulen).

Die Bedeutung des MVC Entwurfsmuster 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 fachlichen Daten und Datenstrukturen (Modell) repräsentiert und welche fachlichen Abläufe (Controller) 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 View, Modell und Controller wird diese dann vorzugsweise mittels des Listener-Entwurfsmuster realisiert, auch diese Infrastruktur wird von GUI-Frameworks mitgeliefert.

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

  1. einen View in Form ausimplementierter GUI Widgets,
  2. den Vertrag für das Modell in Form von Schnittstellen,
  3. den Vertrag für Benachrichtigungen aufgrund von Nutzerinteraktion in Form von Schnittstellen und ausimplementierten Klassen, sowie
  4. den Vertrag für Benachrichtigungen aufgrund 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 Oberfläche.

Beispiel

  Abb. 1

Abbildung 1 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 der Controller 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. Der Controller 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 natürlich nur eine von vielen Möglichkeiten für ein MVC-Modell. Aber es zeigt die grundlegende Funktionsweise des MVC-Modells. An der Abbildung lässt sich auch 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:


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).

Im Gegensatz zu allgemeinen Client/Server-Anwendungen, dient MVC2 in Webanwendungen der Trennung eines Controllers, der HTTP-Requests verarbeitet, von einer View, die HTML-Responses erzeugt. Das einmalige Senden der Response geschieht durch einen Updatekontrollfluss vom Controller zum View.

Siehe auch

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Model_View_Controller&oldid=16814213“