Model-View-Controller-Paradigma

Dieser Artikel erfüllt die GlossarWiki-Qualitätsanforderungen nur teilweise:

Korrektheit: 4 (großteils überprüft)

Umfang: 3 (einige wichtige Fakten fehlen)

Quellenangaben: 4 (fast vollständig vorhanden)

Quellenarten: 4 (sehr gut)

Konformität: 4 (sehr gut)

Diese Bewertungen beziehen sich auf alle im nachfolgenden Menü genannten Artikel gleichermaßen.

Definition

Als Model-View-Controller-Paradigma, kurz MVC-Paradigma oder MVC, bezeichnet man ein Architekturmuster, bei der eine Anwendungs-Komponente in drei eigenständige Module unterteilt wird: Model (Modell), View (Darstellung, Präsentation) und Controller (Steuerung).

Model (Modell)

Das Modell speichert als zentrales Modul sämtliche Daten, d.h. den aktuellen Zustand der Komponente, und enthält häufig auch die Komponentenlogik. Die Kommunikation nach außen (beispielsweise Zugriffe auf Datenbanken oder andere Anwendungen) findet im Allgemeinen ebenfalls im Modell statt (vergleiche aber Model-View-Controller-Service-Paradigma).

Eine weitere Aufgabe des Modells kann es sein, andere Module (View und Controller) zu informieren, wenn sich der Zustand des Modells ändert. Änderungen werden i. Allg. unmittelbar mitgeteilt. Oftmals wird hierfür das Observer-Pattern verwendet.

View (Darstellung, Präsentation)

Eine View ist für die Präsentation von Modell-Daten zuständig. Es kann mehrere Darstellungen ein und desselben Modells geben, die die Modell-Daten auf unterschiedlichste Art und Weise repräsentieren (z.B. optisch, akustisch oder auch haptisch). Eine Änderung des Zustandes der Komponente hat i. Allg. eine Anpassung der entsprechenden Views zur Folge.

Controller (Steuerung)

Ein Controller nimmt Eingaben aus verschiedensten Quellen entgegen (z.B. Daten, die ein Benutzer über eine beliebige Schnittstelle oder auch über eine View eingibt) und leitet diese bereinigt und normalisiert an ein Modell weiter. Manchmal ist der Controller auch für die Wahl der zu präsentierenden Views zuständig.

Häufig wird die Komponentenlogik nicht im Modell, sondern im Controller implementiert.

Anmerkungen

Logische Sichten zu verwalten, wie z.B. die Regelung des Zugriffs auf verschiedene Daten abhängig von den Benutzerrechten, ist nicht die Aufgabe einer View, sondern Aufgabe eines Modells oder eines Controllers.

Gerade weil umstritten ist, ob die Komponentenlogik besser im Modell oder besser im Controller angesiedelt wird, sollte man das Logik-Modul als eigenständiges Modul realisieren. Dies wird beispielsweise im VCLSD-Paradigma umgesetzt.

MVC-Paradigma: Varianten

• Besipiel für eine VCM-Schichtenarchitektur
  Besipiel für eine VCM-Schichtenarchitektur
• Besipiel für eine CVM-Schichtenarchitektur
  Besipiel für eine CVM-Schichtenarchitektur

VCM-Paradigma

Ein MVC-Paradigma wird VCM-Paradigma genannt, wenn die drei zugehörigen Module folgende Schichtenarchitektur bilden: View, Controller, Model.

Das heißt, die View-Module können direkt (z.B. via Unicast-Nachrichten) auf die Controller- und Modell-Module zugreifen und die Controller-Module können direkt auf Modell-Module zugreifen. Alle anderen „Zugriffe“ erfolgen nur indirekt (z.B. als Antworten auf Unicast-Nachrichten oder mittels Multicast-Nachrichten).

CVM-Paradigma

Ein MVC-Paradigma wird CVM-Paradigma genannt, wenn die drei zugehörigen Module folgende Schichtenarchitektur bilden: Controller, View, Model.

Das heißt, die Controller-Module können direkt (z.B. via Unicast-Nachrichten) auf die View- und Modell-Module zugreifen und die View-Module können direkt auf Modell-Module zugreifen. Alle anderen „Zugriffe“ erfolgen nur indirekt (z.B. als Antworten auf Unicast-Nachrichten oder mittels Multicast-Nachrichten).

reines MVC-Paradigma

Ein MVC-Paradigma wird rein genannt (Pure MVC Paradigm), wenn alle Module nur indirekt, d.h. mit Hilfe von Multicast-Nachrichten kommunizieren. (vgl. PureMVC)

MVC-Pattern

Wenn für ein MVC-Paradigma – im Sinne eines Entwurfmusters – eine konkrete Klassen- und Objekt-Struktur für die drei Module Model, View und Controller vorgegeben ist, spricht man von einem MVC-Pattern.

VCM-Pattern

Ein MVC-Pattern, das ein VCM-Paradigma realisiert, wird auch VCM-Pattern genannt.

CVM-Pattern

Ein MVC-Pattern, das ein CVM-Paradigma realisiert, wird auch CVM-Pattern genannt.

CVM-Pattern

Ein MVC-Pattern, das ein reines MVC-Paradigma realisiert, wird auch reines MVC-Pattern genannt.

MVC-Prozesse

[[Medium:MVC-Prozess 01.png|gerahmt||rechts|MVC-Prozess (in Anlehnung an Reenskaug (2003), Slide 17 auf Seite 10, sowie Commons:File:MVC-Process.svg)]] Die Aufgaben, die die einzelnen Module des MVC-Paradigmas wahrnehmen, lassen sich als Interaktionsprozesse zwischen diesen Modulen darstellen. Im Folgenden werden mehrere Varianten von derartigen Interaktionsprozessen beschrieben.

Ursprünglich wurde das MVC-Paradigma von Reenskaug entwickelt. In Reenskaug (2003) ist der grundlegende MVC-Prozess beschrieben: Die Anwendungsdomäne wird im so genannten Modell (Model) nachgebildet. Dieses informiert eine oder mehrere Views über jede Änderung des aktuellen Zustands. Dem Benutzer (User) wird der aktuelle Zustand des Modells von einer oder mehrere dieser Views präsentiert. Über die Steuerung (Controller) kann der Benutzer das Modell manipulieren, das heißt, dessen Zustand (und damit auch die zugehörigen Darstellungen) ändern.

Beispiel Jump 'n' Run

In einem Jump-'n'-Run-Spiel werden im Modell Daten über die Spielfigur (Position, Laufrichtung, Geschwindigkeit ...), die Gegner, die Gegenstände etc. gespeichert.

Das Darstellungsmodul visualisiert die Elemente des Spiels mit Hilfe von Bildern und Animationen (Walk cyles etc.). Jede Änderung im Modell hat, sofern sie sich im für den Spieler sichtbaren Bereich befindet, eine Anpassung der Darstellung zur Folge.

Der Spieler steuert die Spielfigur mit Hilfe der Tastatur. Jeder Tastendruck wird vom Steuerungsmodul analysiert und zur Manipulation der Spielfigur an das Modell weitergeleitet.

Man beachte, dass das Modell i. Allg. aktiv ist, d.h. seinen Zustand selbstständig auch ohne Manipulatation durch die Steuerkomponete verändern kann. Beispielsweise werden die gegnerischen Figuren, sofern es welche gibt, vom Modell selbst bewegt.

Erweiterung des MVC-Prozesses

gerahmt|rechts|MVC-Prozess 2 (mit erweiterter Interaktion) Im zurvor beschriebenen MVC-Prozess kommuniziert der Benutzer direkt mit einer Steuerkomponente. Dies ist z.B. bei einer Tastatur-Steuerung, bei Verwendung von Webcam und Mikrofon oder bei einer Kommunikation über eine Daten-Schnittstelle (wie z.B. eine serielle Schnittstelle oder einen USB-Controller) möglich.

Meist werden jedoch dem Benutzer Interaktionselemente (wie Button, Slider und Texteingabe-Felder) über eine View präsentiert. In so einem Fall sollte die Darstellungkomponete die Benutzereingaben nicht selbst verarbeiten, sondern an ein zuständiges Steuerungsmodul weiterleiten.

Eine weitere Verfeinerung des zuvor beschriebenen Prozessablaufs wird bei der Kommunikation zwischen Modell und Controller vorgenommen: Das Modell kann nicht nur die View, sondern auch die auch die Steuerung direkt über Änderungen informieren, damit dieser dem User gegebenfalls ein Feedback (z.B. Force Feedback) geben kann. Hier kann man allerdings auch argumentieren, dass diese Art der Informations-„Visualisierung“ Aufgabe einer View wäre. Das heißt, im Allgemeinen kann die Steuerung darauf verzichten, auf Modellereignisse zu hören und zu reagieren.

VCM-Prozess

gerahmt|rechts|VCM-Prozess</ref> gerahmt|rechts|CVM-Prozess, Sequenzdiagramm

Die zuvor beschriebenen erweiterten Kommunikationsmöglichkeiten können sehr elegant als VCM-Prozess realisert werden. Das heißt, eine View leitet Benutzeraktionen direkt an einen geeigneten Controller weiter. Jeder Controller bereitet die eingehenden Daten geeignet auf und aktiviert die zugehörigen Kommandos zum Modifizieren von Modelldaten. Ob diese Kommandos (= Komponentenlogik) im Controller oder im Modell angesiedelt sind, hängt von der speziellen Umsetzung des VCM-Paradigmas ab. Jedes Modell informiert per Multicast-Nachricht alle interessierten Controller und Views. Diese können auf die Änderungen geeignet reagieren. Wenn das Model in seinen Nachrichten nicht alle Änderungsinformation mitschick, können die View und die Controller per direktem Zugriff nach weitere Informationen zur jeweiligen Änderung einholen.

Die direkte Kommunikation per Unicast-Nachrichten zwischen View und Controller, ziwchen View und Modell sowie zwischen Controller und Modell ist i. Allg. problemlos möglich, da in jedem Fall die Kommunikationspartner beim Initialisieren der Komponente eindeutig festliegen. Dies ist jedoch bei den Kommunikationspartnern der Modelle nicht der Fall: Die Anzahl der Views (und evtl. auch der Controller), die nach einer Modelländerung aktualisiert werden müssen, liegt nicht von vorn herein fest und kann sich jederzeit ändern. Daher ist in diesem Fall eine indirekte Kommunikation mit Hilfe von Multicast-Nachrichten deutlich sinnvoller.

Sequenzdiagramm

Im zugehörigen Sequenzdiagramm werden drei verschiedene Kommunikationsvorgänge exemplarisch dargestellt. Der Benutzer registriert Änderungen an einer View stets asynchron. Das heißt, die View hat keinen Einfluss darauf, wann der Benutzer welchen Teil der View betrachtet.

Der erste Kommunikationsvorgang ist relativ simpel. Der Benutzer aktiviert einen Controller (z.B. per Tastenklick). Dies hat eine Modifikation des zugehörigen Modells zur Folge. Das Modell informiert die zugehörige View per Multicast. Die daraus resultierende Änderung der View wird irgendwann vom Benutzer wahrgenommen.

Der zweite Kommunikationsvorgang unterscheidet sich vom ersten dadurch, dass der Benutzer mit der View interagiert. Die muss die Benutzeraktion (z.B. Aktivierung eines Button per Mausklick) zunächst an einen Controller weiterleiten. Danach läuft der Kommunikationsprozess genauso wie zuvor ab.

Im dritten Fall hat die Benutzeraktion und die darufhin ausgeführte Modellmodifikation mehrere Aktionen zu Folge. Es werden sowohl der Controller, als auch die View über die Änderung informiert. Beide erfragen weitere Details über diese Änderung vom Modell, bevor sie ihren Zustand ändern, der dann jeweils vom Benutzer wahrgenommen werden kann.

Beispiel „Warenkorb“

In einer clientseitigen Warenkorb-Anwendung werden im Modell Daten über den Warenkorb und – sobald sich der Besteller eingeloggt hat – den zugehörigen Besitzer gespeichert: der Warenkatalog, eine aktuelle Auswahl des Warenkataloges, der Inhalt des Warenkorbs, der Gesamtpreis der Waren im Warenkorb, die Anschrift des Bestellers etc. Die Modelldaten oder zumindest Teile davon (wie z.B. der Warenkatalog) werden häufig in einer Datenbank abgelegt (siehe auch Model-View-Controller-Service-Paradigma).

Ein Darstellungsmodul visualisiert Modelldaten, wie z.B. die aktuelle Auswahl des Warenkataloges, mit Hilfe von Texten, Bildern und Videos. Der Benutzer kann die Auswahl der visualierten Elemente durch Filter oder Navigation abändern, er kann Elemente des Kataloges in seinen Warenkorb legen und dort wieder entfernen etc. Für all diese Aktionen werden dem Benutzer in der View spezielle Eingabefelder (Checkboxes, Drop-Down-Menüs, Textfelder, Links etc.) angeboten. Jedes mal, wenn der Benutzer eines dieser Elemente mit Hilfe der Maus oder der Tastatur bedient, leitet das zugehörige Darstellungsmodul eine entsprechende Nachricht an die Steuerung weiter.

Die Steuerung analysiert die geünschte Aktion des Benutzers und führt die entsprechenden Änderungen im Modell durch. Zum Beispiel kann sie veranlassen, dass die aktuelle Auswahl des Warenkataloges den Wünschen des Benutzers gemäß geändert wird.

Beispiel „Advanture Game“

In einem Abenteuerspiel wird häufig sowohl die aktuelle Szene, als auch eine Übersichtskarte mit allen bereits erkundeten Bereichen visualisiert. Wenn an diesem Spiel mehr als ein Spieler beteiligt sind, gibt es sogar zahlreiche verschiedene Visualisierungen (aus Sicht eines jeden Spielers mindestens eine!).

Hier wäre eine direkte Kommunikation zwischen Modell und View extrem unpraktisch.

Kommunikation zwischen zwei VCM-Komponenten

gerahmt|Zwei miteinander kommunizierende VCM-Prozesse

Auch der VCM-Prozess beschreibt das allgemeine Vorgehen häufig etwas ungenau. Viele Anwendungen bestehen aus mehreren VCM-Komponenten: Eine oder mehrere Kernanwendungen (Domain-Komponenten) sowie einer Rahmenanwendung (Frame-Komponente), die den Zugang zu und zwischen den Kernanwendungen steuert. In diesem Fall gibt es mehrere relativ unabhängige MVC-Prozesse. Die äußeren Komponenten (wie z.B. die Rahmenkomponente) können dabei mit den inneren Komponenten (wie z.B. die Kernkomponenten) kommunizieren. Der umgekehrte Weg sollte vermieden werden, damit Kernkomponenten problemlos in andere Umgebungen integriert werden können.

Man beachte, dass die innere View in die äußere View eingebettet werden kann. Ansonsten sind die einzelnen Komponenten möglichst eigenständig und kommunizieren nur über wohldefinierte und möglichst schlanke Schnittstellen miteinander.

Beispiel Jump-'n'-Run-Spiel mit Trainingsmodus und Highscore

Man kann das Jump-'n'-Run-Spiel aus dem ersten Beispiel als Kernanwendung in einen Rahmen einbetten, der den Zugang zu diesem Spiel ermöglicht. Zum Beispiel kann die Rahmenanwendung verlangen, dass sich der Benutzer erst anmelden muss, bevor er mit dem Spiel beginnen kann. Danach kann der Benutzer wählen, ob er ein neues Spiel starten, ein altes Spiel fortsetzen oder ein bestimmtes Level im Trainigsmodus üben will. Die Rahmenanwendung kann darüber hinaus das Spiel mit einer Highscore-Anwendung (eine weitere Kernanwendung) koppeln, die für beliebige Spiele benutzerspezifische Scores sowie jeweils einen Highscore verwaltet.

Wenn der Benutzer zum Beispiel den Trainigsmodus aktivieren möchte, kann die Steuerung der Rahmenkomponente zunächst mit Hilfe der Highscore-Anwendung ermitteln, ob der Benutzer schon genügend Punkte erspielt hat. Hierzu muss der die Highscore-Steuerung veranlassen, die gewünschten Daten im Higscore-Modell bereit zu stellen. Die Rahmen-Steuerung greift dann über das Rahmen-Modell darauf zu. Anschließend, sofern der Benutzer bereits genügnd Spielerfahrung hat, leitet die Rahmen-Steuerung den Wunsch nach Aktivierung des Trainingsmoduses Steurung des Spiels weiter.

CVM-Prozess, Model 2

gerahmt|rechts|CVM-Prozess, Model 2[2] gerahmt|rechts|CVM-Prozess, detailliertere Darstellung des Kommunikationsprozesses gerahmt|rechts|CVM-Prozess, Sequenzdiagramm

Spezielle MVC-Paradigmen haben sich nicht nur im Bereich der interaktiven Anwendungen etabliert, sondern auch im Bereich der Web-Frameworks. In der Spezifikation von JSP 0.92 wurde das Model 2 eingeführt, welches eine MVC-Architektur beschreibt, das so oder so ähnlich Basis vieler Web-Frameworks ist.

Hier läuft der Kommunikations-Prozess stets synchron ab: Ein Client (wie z.B. ein Web-Browser) übermittelt an einen Controller eine Anfrage (z.B. in Form einer URL plus weiteren Daten) und wartet dann auf eine Antwort: eine View, die er dem Benutzer präsentieren kann. (Dies gilt sogar, wenn Ajax zu Einsatz kommt. Auch hier wartet der Client, bis die Anwort eingetroffen ist. Die als Ergebnis gelieferte Teilview wird dann vom Client verwendet, um die aktuell dem Benutzer präsentierte View zu aktualisieren.)

Um eine Antwort generieren zu können, leitet der Controller die erhaltenen Daten an das Modell weiter. Sobald das Modell die Daten vollständig verarbeitet hat, meldet es den Erfolg oder Misserfolg dieser Verarbeitung an den Controller. Daraufhin stößt der Controler die Erzeugung (das Rendering) einer View an. Welche View erzeugt wird, hängt dabei von den Daten (insbesondere der URL) ab, die dem Controller übergeben wurden, sowie von der Antwort des Modells auf die Übermittlung dieser Daten. Wenn das Modell beispielsweise meldet, dass die Berechtigung zum Zugriff auf die gewünschten Daten fehlt, wird der Controller eine Login-View generieren, anderenfalls wird er eine View erzeugen, die die gewünschten Informationen präsentiert.

Der View-Renderer kann beliebig oft auf das Modell zugreifen, um Daten zu erfragen, die in die View integriert werden. Sobald der Rendervorgang abgeschlossen ist, erhält der Controller die erzeugte View. Der Controller leitet diese als Antwort an den Client zurück.

Beispiel „JSP“

Den meisten „Web Application Frameworks“ liegt heutzutage ein MVC-Paradigma zugrunde (vgl. MVC-Paradigma/Umsetzungen). Fast immer wird das MVC-Paradigma dabei als CVM-Paradigma realisiert.

Java-basierte Web-Frameworks, wie z.B. Apache Struts, JSF oder auch das Spring Web MVC framework, rendern die Views häufig mit Hilfe von JavaServer Pages (JSP). Als Modelle kommen in derartigen Frameworks normalerweise JavaBeans zum Einsatz. Sofern in einer Web-Anwendung die JSP-Seiten auch die Aufgaben des Controllers übernehmen, spricht man von einer Model-1-Architektur.

Wenn in einen Web-Framework dagegen spezielle Servlets die Controller-Funktionalität, d.h. die Views von dieser Funktionalität befreit werden, handelt es sich um eine CVM-Architektur, die im JSP-Umfeld allerdings Model-2-Architektur genannt wird.

Die Controller werden entweder in der web.xml des zugehörigen Web-Server konfiguriert oder mit Hilfe von speziellen XML-Dateien.

Die Controller-Konfigurationsdatei struts.xml einer Hello-World-Anwendung in Struts könnte beispielsweise folgendermaßen aussehen:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE struts PUBLIC
  "-//Apache Software Foundation//DTD Struts Configuration 2.0//EN"
  "http://struts.apache.org/dtds/struts-2.0.dtd">

<struts>	 
  <package name="Login" extends="struts-default">	 
    <action name="LoginAction" class="hello.LoginAction">
      <result name="input">/Login.jsp</result>
      <result name="success">/HelloWorld.jsp</result>
    </action>
  </package>
</struts>

Die Klasse hello.LoginAction, übernimmt die eigentliche Controll-Funktionalität. Von einem Objekt dieser Klasse wird die Methode execute aufgerufen. Dies Methode hat Zugriff auf die vom Benutzer übergebenen Daten, kann diese Daten in ein Modell eintragen oder anderweitig verarbeiten und liefert schließlich einen Ergebnis-String. Abhängig vom Wert dieses String wird eine in der struts.xml spezifizierte View generiert.

Ein anderes Beispiel ist das Web MVC Framework von Spring. Hier nimmt der so genannte Front Controller die Anfragen (Requests) vom Client entgegen und leitet diese an ein zweiten Controller weiter. Dieser erzeugt ein Modell-Objekt, initialisiert es und liefert es an den Front Controller zurück. Der Front Controller startet daraufhin einen View-Rendervorgang. Er übergibt dem View-Renderer das Model als Parameter, damit der Render darauf zugreifen kann.

Bemerkungen

Vorteile

Das MVC-Paradigma ermöglicht ein flexibles Programmdesign, welches die Wiederverwendbarkeit der einzelnen MVC-Module und komplexer MVC-Komponenten sowie eine daraus resultierende reduzierte Gesamtkomplexität gewährleistet, insbesondere bei großen Anwendungen. Folgende Vorteile ergeben sich insbesondere:

• Die Anwendungslogik ist von den dazugehörenden Darstellungen und den Benutzerinteraktionen klar getrennt: Seapration of Concern.
• Ein Modell kann durch viele Darstellungsmodule repräsentiert werden (z.B. Detail-View und Übersichts-View wie z.B. eine Landkarte mit Akteuren, spielerspezifische Views bei Multiuser-Spielen, vierschiedene Ansichten eines 3D-Modells etc.).
• Bei Multiuser-Spielen muss nur das Modell auf allen beteiligten Rechnenr synchronisiert werden. Eine realtive geringe Bandbreite reicht zur Übertragung aus.
• Bestehende Systeme können einfach erweitert werden, indem neue Module und MVC-Komponenten hinzugefügt werden.

Nachteile

• Bei kleinen Anwendungen bedeutet der Einsatz von MVC einen gewissen Mehraufwand.

Anwendungsgebiete

• Allgemein: größere Softwareprojekte
• GUI-Programmierung (bspw. Frameworks wie Swing)
• Web-Anwendungen (bspw. Frameworks wie Ruby on Rails)
• Beispiele für Umsetzungen des Model-View-Controller-Paradigmas

Quellen

• Kowarschick, W.: Multimedia-Programmierung
• Reenskaug, T. (1979): Thing-Model-View-Editor (Erste Notiz mit exemplarischen Beispielen)
• Reenskaug, T. (1979a): Models-Views-Controllers (Grundlegende Definition von MVC)
• Reenskaug, T. (2003): The Model-View-Controller (MVC). Its Past and Present
• Stoiber, D. (2005): Implementierung des Model-View-Controller Paradigmas
• Martin Fowler: GUI Architectures
• WikipediaEN:Model–view–controller
• Wikipedia:Model View Controller

Siehe auch

• Model-View-Controller-Paradigma/Umsetzungen
• Model-View-Controller-Service-Paradigma
• View-Controller-Logic-Service-Data-Paradigma
• Homepage von Trygve M. H. Reenskaug, Erfinder von MVC
• Reenskaugs eigene Seite über MVC
• Wikipedia:Model View_Controller
• Joe Berkovitz: MVCS

Dieser Artikel ist GlossarWiki-konform.