Model-View-Controller-Paradigma

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg

Definition

Das Model-View-Controller-Paradigma oder -Pattern, kurz MVC, bezeichnet ein Architekturmuster zur Trennung einer Anwendung in drei separate Einheiten: Model (Modell), View (Illustration, Präsentation, Darstellung) und Controller (Steuerung).

Konzept

Es gibt keinen Standard, der festlegt, wie MVC umzusetzen ist. Je nach Anwendungsgebiet sind manche Komponenten wichtiger als andere. Auch kann nicht immer pauschal festgelegt werden, wo gewisse Funktionen eindeutig hingehören. Hier unterscheiden sich viele MVC-Realisierungen teilweise ziemlich deutlich.

Im Prinzip lassen sich die Bereiche jedoch grob eingrenzen:

Model (Modell)

Das Modell speichert als zentrale Komponente sämtliche Daten und enthält die Applikationslogik. Die Kommunikation nach außen (beispielsweise Zugriffe auf Datenbanken oder andere Anwendungen) findet im Allgemeinen ebenso im Modell statt (vergleiche aber Model-View-Controller-Services-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, ander Kompnenten (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 (Illustration, Präsentation, Darstellung)

Die Präsentationskomponente ist für die Ausgabe der Modell-Daten zuständig und bildet eine Abstraktionsschicht zwischen der Präsentation der Anwendung, dem Modell und dem Benutzer. Es kann mehrere Darstellungen ein und desselben Modells geben, die die Modell-Daten auf technische oder optische Art und Weise unterschiedlich repräsentieren. Verschiedene logische Sichtweisen bleiben dem Modell vorbehalten (bspw. verschiedene Benutzeransichten: Administrator, Redakteur, Gast).

Controller (Steuerung)

Die Steuerung nimmt Eingaben aus verschiedensten Quellen entgegen und leitet diese bereinigt und normalisiert an das Modell weiter. Hier wird also weitere Abstraktionsschicht eingeführt, die die Verbindung zwischen Benutzer-Interaktionen und dem Modell beschreibt.

Der MVC-Prozess

[[Medium:MVC-Prozess 01.png|gerahmt||rechts|MVC-Prozess (in Anlehnung an Reenskaug (2003), Slide 17 auf Seite 10, sowie Wikipedia (en): File:MVC-Process.png)]] Das MVC-Paradigma basiert auf folgender Grundüberlegung: Die Anwendungsdomäne wird im so genannten Modell (Model) nachgebildet. Dem Benutzer (User) wird der aktuelle Zustand des Modells mit Hilfe beliebig vieler Darstellungen (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.

Die Darstellungskomponente 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 von der Steuerungskomponente 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 Manipultation 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 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 eine zuständige Stzeuerungskomponente weiterleiten.

Eine weitere Verfeinerung des vorangegangenen Prozess-Modells wird bei der Kommunikation zwischen Modell und View vorgenommen. Zu einem Modell kann es beliebig viele Views geben (beispielsweise kann jeder Spieler eines Multi-User-Games eine eigene View der Spielszene, d.h. des Modells präsentiert bekommen). Das Modell informiert alle angeschlossenen Darstellungskomponenten darüber, dass sich die Daten im Modell geändert haben. Die Views können daraufhin die für sie entsprechenden Änderungen vornehmen, d.h. die Darstellung an die neuen Gegebenheiten anpassen.

Ebenso kann das Modell auch die Steuerung direkt informieren, damit dieser über dem User ein Feedback (z.B. Force Feedback) geben kann. Hier könnte 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 Model-Ereignisse zu hören und zu reagieren.

Beispiel Warenkorb

In einer Warenkorb-Anwendung werden im Modell Daten über den Warenkorb und den Benutzer (sobald dieser eingeloggt ist) gespeichert: Der Gesamt-Warenkatalog, eine aktuelle Auswahl des Warenkataloges, den Inhalt des Warenkorbs, der Gesamtpreis und die Versandkosten der Waren im Warenkorb etc. Die Modell-Daten oder zumindest Teile davon (wie z.B. der Gesamt-Warenkatalog) werden häufig direkt oder indirekt (vgl. Model-View-Controller-Services-Paradigma) in einer Datenbank abgelegt.

Eine Darstellungskomponente visualisiert Modell-Daten, 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 ([Checkbox]]es, 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 die zugehörige Darstellungskomponente 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 ziwschen den MVC-Komponenten

gerahmt|rechts|MVC-Prozess 2b Ein wichtiges Programmier-Prinzip ist es, so wenige Abhängigkeiten wie möglich zu erzeugen, da Abhängigkeiten die Komplexität und die Fehleranfälligkeit erhöhen. Die Abhängigkeiten entstehen dadurch, dass die MVC-Komponenten miteinander kommunizieren müssen.

Für die Kommunikation zwischen den drei MVC-Komponenten „Model“, „View“ und „Controller“ gibt es mehrere Möglichkeiten:

  1. Eine Komponente hat direkten Zugriffe auf eine zweite (durchgezogene Linie im Diagramm „MVC-Prozess 2b“).
  2. Eine Komponente (Sender) informiert beliebig viele andere Komponenten (Empfänger) mit Hilfe von Multicast-Nachrichten (Entwurfsmusters „Beobachter“, gestrichelte Linie im Diagramm „MVC-Prozess 2b“).
    1. Der Sender informiert mit der Nachricht die Empfänger lediglich, dass sich etwas geändert hat. Die Empfänger müssen sich daraufhin die für sie wichtigen Information per direktem Zugriff vom Sender holen.
    2. Der Sender schickt in der Nachricht detailierte Informationen mit, so dass der Empfänger nicht noch einmal auf den Sender zugreifen muss.

Eine Modellkomponente sollte vollkommen unabhängig von anderen Komponenten existieren. Sie stellt lediglich Methoden zur Verfügung, mit deren Hilfe irgendwelche Steuerungskomponenten die Daten des Modells manipulieren können. Mit Hilfe von Mulitcast-Nachrichten informiert ein Modell die übrigen Komponenten über erfolgte Änderungen. Dabei muss sich der Programmierer entscheiden, ob mit einer derartigen Nachricht detailierte Informationen über die Änderungen mitgeschickt werden (2.2) oder nicht (2.1).

Man beachte, dass bei der Implementierung einer Modellkomponente weder die Steuerungs- noch die Darstellungskomponenten bekannt sein müssen.

Eine Darstellungkomponente lauscht auf Nachrichten einer oderer mehrerer Modellkomponenten. Sie muss diese Modelle kennen, um sich zum Nachrichten-Empfang anmelden zu können und um gegebenfalls nähere Informationen über die aktuelle Änderung vom Sender-Modell einholen zu können.

Interaktive Darstellungskomponenten müssen außerdem die zugehörigen Steuerungskomponenten über User-Aktionen informieren. Dies kann entweder direkt (1.) oder mit Hilfe von Multicast-Nachrichten erfolgen (2.). Im ersten Fall müssen die Darstellungskomponenten die zugehörigen Steuerungskomponenten kennen, damit sie diese direkt informieren können. Im zweiten Fall müssen dagegen die Steuerungskomponenten die zugehörigen Darstellungskomponenten kennen, bei denen sie sich als Empfänger anmelden und gegebenfalls Detail-Informationen zu bestimmten Änderungen erfragen. Hier lässt sich micht pauschal festlegen, welche Art der Kommunikation vorzuziehen ist.

Aus Gründen der Modularität sollten diejenigen Darstellungskomponenten, die lediglich Modell-Daten visualisieren, und die Darstellungskomponenten mit interaktiven Elementen möglichst getrennt realisiert werden.

Eine Steuerungskomponente schließlich manipuliert ein oder mehrere Modellkomponenten. Dies sollte stets per direktem Zugriff erfolgen, damit die Modellfunktionalität nicht von der Existenz spezieller Steuerungskomponenten abhängt.

Verfeinerung des MVC-Prozesses

Auch dieser Prozess beschreibt das allgemeine Vorgehen häufig etwas ungenau. Viele Anwendungen bestehen aus zwei (oder noch mehr) Teilen: Der eigentlichen Kern-Anwendung (Domain) und einer Rahmen-Anwendung (Frame), die den Zugang zur Kern-Anwendung und evtl. weiteren Anwendungen steuert. In diesem Fall gibt es zwei (oder mehrere) relativ unabhängige MVC-Prozesse. Die Rahmen-Komponenten können dabei auf Kern-Komponenten zugreifen. Der umgekehrte Weg sollte vermieden werden, damit die Kern-Komponente problemlos in andere Umgebungen integriert werden kann. gerahmt|links|MVC-Prozess 3 (mit Trennung in Frame und Domain)

Man beachte, dass die Kern-View in die Rahmen-View eingebettet werden kann. Ansonsten sind die einzelnen Komponenten möglichst eingenständig und kommunizieren nur über wohldefinierte und möglichst schlanke Schnittstellen miteinander.

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

Man kan das Jump-'n'-Run-Spiel aus dem ersten Beispiel als Kern-Anwendung in einen Rahmen einbetten, der den Zugang zu diesem Spiel ermöglicht. Zum Beispiel kann die Rahmen-Anwendung 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 Rahmen-Anwendung kann darüber hinaus das Spiel mit einer Highscore-Anwendung (eine weitere Kern-Anwendung) 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 Rahmen-Steuerung 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.

Bemerkungen

Vorteile

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

  • Die Anwendungslogik ist von den dazugehörenden Darstellungen und den Benutzerinteraktionen klar getrennt: Seapration of Concern.
  • Ein Modell kann durch viele Darstellungskomponenten 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 wedern, indem neue 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

Quellen

Siehe auch


Dieser Artikel ist GlossarWiki-konform.
Abgerufen von „https://glossar.hs-augsburg.de/w/index.php?title=Model-View-Controller-Paradigma&oldid=14444“