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, bezeinet man ein Architekturmuster, bei der eine Anwendungs-Komponente in drei eigenständige Module unterteilt wird: Model (Modell), View (Darstellung, Präsentation) und Controller (Steuerung).

Im Modell ist der aktuelle Zustand der zugehörigen Komponente abgelegt. Teile der im Modell enthaltenen Informationen werden einem oder mehreren Benutzern mit Hilfe von Views präsentiert. Eine Änderung des Zustandes hat i. Allg. eine Anpassung der entsprechenden Views zur Folge. Der Controller dient dazu, den im Modell gespeicherten Zustand zu modifizieren (häufig als direkte Reaktion auf Benutzerinteraktionen).

Die Programmlogik wird – abhängig von der konkreten Umsetzung des Paradigmas – entweder im Controller oder im Modell implementiert.

MVC-Paradigma

Eine Anwendung oder ein Programmsystem beruht auf dem MVC-Paradigma, wenn das Prinzip der Aufteilung zentraler Komponenten in die drei Module Model, View und Controller wesentlicher Bestandteil dieser Anwendung bzw. dieses Systems ist.

MVC-Pattern

Wenn darüber hinaus – 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.

Der MVC-Prozess

[[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 Interaktionsprozess zwischen diesen Modulen darstellen: 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ädig 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 der Steuerkomponete. 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.

Beispiel „Warenkorb“

In einer 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.

Kommunikation zwischen zwei MVC-Komponenten

Auch der verfeinerte MVC-Prozess beschreibt das allgemeine Vorgehen häufig etwas ungenau. Viele Anwendungen bestehen aus mehreren MVC-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. gerahmt|links|MVC-Prozess 3 (mit Trennung in innere und äußere MVC-Komponenten)

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.

Konzept

Es gibt keinen Standard, der festlegt, wie MVC umzusetzen ist. Je nach Anwendungsgebiet sind manche Module wichtiger als andere. Auch kann nicht pauschal festgelegt werden, welches Modul für welche Funktionen zuständig ist. Hier unterscheiden sich viele MVC-Realisierungen teilweise ziemlich deutlich.

Im Prinzip lassen sich die Bereiche jedoch wie folgt eingrenzen:

Alternativer MVC-Prozess für die Kommunikation eines Clients mit einem Server

gerahmt|rechts|MVC-Prozess (synchrone Kommunkikation) gerahmt|rechts|MVC-Prozess (synchrone Kommunkikation), Verfeinerte Darstellung der Reihenfolge der Kommuikationsschritte

Das MVC-Pattern hat sich nicht nur im Bereicht der interaktiven Anwendungen etabliert, sondern auch im Bereich der Web-Server.

Hier läuft der Kommunikations-Prozess allerdings 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 in Form einer 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 Teil-View 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 vorangegangenen Antwort des Modells. Wenn das Modell beispielsweise meldet, dass die Berechtigung zum Zugriff auf die gewünschten Daten fehlt, wird der Controller beispielsweise eine Login-View generieren, anderenfalls wird er eine View mit den gewüschten Daten erzeugen.

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 ein MVC-Paradigma zugrunde. Java-basierte Frameworks rendern die Views häufig mit Hilfe von JavaServer Pages (JSP). Beispiele für derartige Frameworks sind Apache Struts, JSF oder auch das Spring Web MVC framework. Als Modelle kommen in derartigen Frameworks normalerweise JavaBeans zu Einsatz.

Model (Modell)

Das Modell speichert als zentrales Modul sämtliche Daten und enthält häufig auch die Anwendungslogik. 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). Zudem speichert das Modell den aktuellen Anwendungsstatus, also den Zustand, in dem sich die Anwendung bei der Interaktion mit dem Benutzer befindet.

Eine weitere Aufgabe des Modells ist es, 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)

Das Präsentationsmodul ist für die Ausgabe der 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).

Logische Sichten bleiben hingegen dem Modell vorbehalten. Zum Beispiel ist das Modell dafür zuständig, dass ein Administrator Zugriff auf andere (mehr) Daten hat als ein Redakteur oder Standard-Benutzer.

Controller (Steuerung)

Die Steuerung nimmt Eingaben aus verschiedensten Quellen entgegen (z.B. Daten, die ein Benutzer über die View eingibt) und leitet diese bereinigt und normalisiert an das Modell weiter.

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

Anmerkung

Gerade weil umstritten ist, ob die Anwendungslogik Bestandteil des Modells oder des Controllers ist, sollte man das Logik-Modul als eigenständiges Modul realisieren. Dies wird im VCLSD-Paradigma umgesetzt.

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.

Geschichte

In den Anfängen der Informatik war es nicht unüblich Spaghetti-Code zu entwickeln, was mit vielen Nachteilen verbunden ist. Erst die Einführung der strukturierten Programmierung in den 70er-Jahren und später die objektorientierte Programmierung in den 80er-Jahren schaffte Abhilfe und ermöglichte das Programmieren nach dem Model-View-Controller-Paradigma.

Ursprünglich wurde das MVC-Paradigma 1978/79 von der Firma Xerox für die GUI-Programmierung eingeführt. Zum Einsatz kam die damals ebenfalls von Xerox entwickelte objektorientierte Programmiersprache Smalltalk.

In neueren Programmiersprachen wie Java kommt MVC ebenfalls bei der GUI-Programmierung zum Einsatz. MVC ist heute allgemeiner Standard beim Entwurf komplexer Softwaresysteme, bei denen die Anwendungslogik von anderen Teilen des Systems getrennt werden soll.

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.