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 (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

Das Model (hier wird durchgängig die englische Schreibweise verwendet) 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 Model statt (vergleiche aber Model-View-Controller-Services-Paradigma). Zudem speichert das Model den aktuellen Anwendungsstatus, also den Zustand, in dem sich die Anwendung bei der Interaktion mit dem Benutzer befindet.

Eine weitere Aufgabe des Models ist das Verwalten der Views, die es zu benachrichtigen gilt, wenn sich der Zustand des Modells ändert. Änderungen werden unmittelbar mitgeteilt. Oftmals wird hierfür das Observer-Pattern verwendet.

View

Die View ist die zuständige Komponente für die Ausgabe und bildet eine Abstraktionsschicht zwischen der Präsentation der Anwendung, dem Modell und dem Benutzer. Es können mehrere Views ein und dasselbe Model auf technische oder optische Art und Weise repräsentieren. Verschiedene logische Sichtweisen bleiben dem Model vorbehalten (bspw. verschiedene Benutzeransichten: Administrator, Normaluser).

Controller

Der Controller nimmt Eingaben aus verschiedensten Quellen entgegen und leitet diese bereinigt und normalisiert an das Model weiter. Er ist somit eine weitere Abstraktionsschicht, der die Verbindung ziwschen Benutzer-Interaktionen und dem Model realisiert.

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 Model nachgebildet. Dem Benutzer (User) wird der aktuelle Zustand des Models mit Hilfe beliebig vieler Views präsentiert. Über einen Controller kann der Benutzer das Model manipulieren, das heißt, dessen Zustand (und damit auch die zugehörigen Views) ändern.

Beispiel Jump 'n' Run

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

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

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

Man beachte, dass das Model i. Allg. aktiv ist, d.h. seinen Zustand selbststädig auch ohne Manipultation durch den Controller verändern kann. Beispielsweise werden die gegnerischen Figuren, sofern es welche gibt, vom Model selbst bewegt.

Erweiterung des MVC-Prozesses

gerahmt|rechts|MVC-Prozess 2 (mit erweiterter Interaktion) Im zurvor beschriebenen MVC-Prozess kommuniziert der Benutzer direkt mit dem Controller. Dies ist z.B. bei einer Tastatur-Steuerung, Verwendung von Webcam und Mikrofon oder 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 View die Benutzereingaben nicht selbst verarbeiten, sondern an einen zuständigen Controller weiterleiten. Entsprechend wird der MVC-Prozess etwas komplexer (siehe Abbildung „MVC-Prozess 2“).

Beispiel Warenkorb

In einer Warenkorb-Anwendung werden im Model Daten über den Warenkorb und den Benutzer (sobald dieser eingeloggt ist) gespeichert: Der Gesamt-Warenkatalog, eine aktuelle Auswahl des Warenkataloges, die Waren, die im Korb enthalten sind, der Gesamtpreis und die Versandkosten der aktuellen Bestellung etc. Das Model wird häufig direkt oder indirekt (vgl. Model-View-Controller-Services-Paradigma) in einer Datenbank abgelegt.

Die View visualisiert Elemente der aktuellen Auswahl des Warenkataloges (siehe Model) 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.) präsentiert. Jedes mal, wenn der Benutzer eine dieser Felder mit Hilfe der Maus oder der Tastatur bedient, leitet die View eine entsprechende Nachricht an den Controller weiter.

Der Controller analysiert die geünschte Aktion des Benutzers und führt die entsprechenden Änderungen am Model durch. Zum Beispiel kann er veranlassen, die die aktuellen Auswahl des Warenkataloges den Wünschen des Benutzers gemäß geänder

Verfeinerung des MVC-Prozesses

gerahmt|MVC-Prozess 3 (mit Trennung in Frame und Domain) 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 Frame-Komponenten können dabei auf Domain-Komponenten zugreifen. Der umgekehrte Weg sollte vermieden werden, damit die KErn-Komponente problemlos in andere Umgebungen integriert werden kann.

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 Frame-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 Frame-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 der Frame-Controller zunächst mit Hilfe der Highscore-Anwendung ermitteln, ob der Benutzer schon genügend Punkte erspielt hat. Hierzu muss der den Highscore-Contoller veranlassen ,die geünschten Daten im Higscore-Model bereit zu stellen. Der Frame-Contoller greift dann über das Frame-Model darauf zu. Anschließend, sofern der Benutzer bereits genügnd Spielerfahrung hat, leitet der Frame-Controller den Wunsch nach Aktivierung des Trainingsmoduses an den Domain-Controller 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 Model kann durch viele Views 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 Model 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

MVC-Implementierungen

ABAP Objects

ASP

C++

CFML — Adobe ColdFusion, Railo (Java) und Open BlueDragon (Java)

Erlang

Flash/Flex

Groovy

Haxe

Java

JavaScript

Lua

.NET

Objective C

Perl

PHP

Python

Ruby

Smalltalk

XML

  • XForms: Model–View–Controller-Architektur

Quellen

Siehe auch


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