Model-View-Controller-Paradigma: Unterschied zwischen den Versionen

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg
← zur vorherigen Versionen-Differenzzur nächsten Versionen-Differenz →
Kowa (Diskussion | Beiträge)
Administrator, Bots, Bürokraten, emailconfirmed, Oberflächenadministratoren, interwiki, oversight, SMW-Administratoren, SMW-Kuratoren, SMW-Editoren, Oversighter, Administratoren
42.989 Bearbeitungen
Kowa (Diskussion | Beiträge)
Administrator, Bots, Bürokraten, emailconfirmed, Oberflächenadministratoren, interwiki, oversight, SMW-Administratoren, SMW-Kuratoren, SMW-Editoren, Oversighter, Administratoren
42.989 Bearbeitungen
Keine Bearbeitungszusammenfassung
Zeile 27: Zeile 27:
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“).
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 <code>Model</code> 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 <code>Model</code> wird häufig direkt oder indirekt (vgl. [[Model-View-Controller-Services-Paradigma]]) in einer Datenbank abgelegt.


Die <code>View</code> visualisiert Elemente der aktuellen Auswahl des Warenkataloges (siehe <code>Model</code>) 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, [[Textfeld]]er, [[Link]]s 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 <code>Controller</code> analysiert die geünschte Aktion des Benutzers und führt die entsprechenden Änderungen am <code>Model</code> durch.
 
Zum Beispiel kann er veranlassen, die die aktuellen Auswahl des Warenkataloges den Wünschen des Benutzers gemäß geänder
 
 
 
 
 
 
 


[[Medium:MVC-Prozess 03.png|gerahmt|MVC-Prozess 3 (mit Trennung in Frame und Domain)]]
[[Medium:MVC-Prozess 03.png|gerahmt|MVC-Prozess 3 (mit Trennung in Frame und Domain)]]

Version vom 26. Mai 2010, 15:05 Uhr

Definition

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

Der MVC-Prozess

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.

Erweiterungen 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

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. Zum Beispiel kann es sich bei der Kern-Anwendung um Spiel handeln. Die Rahmen-Anwendung kann z.B. die Identität des Benutzers (login) überprüfen, bevor sie Zugriff auf die eigentliche Anwendung gewährt. Oder sie kann eine Highscore für das aktuelle Spiel präsentieren.

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.

Konzept

Es gibt kein hundertprozentiges Patentrezept, 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, da weitere Aspekte der Planung und des Entwurfs die Entscheidung beeinflussen können. Zum Beispiel kann es sinnvoll sein, aus Sicherheitsgründen eine Benutzerauthentifizierung einer Webanwendung nicht im Controller sondern im Modell abzulegen. Im Prinzip lassen sich die Bereiche jedoch grob eingrenzen:

Model

Das Modell speichert als zentrale Komponente sämtliche Daten und enthält die Applikationslogik. Die Kommunikation nach außen (außerhalb der Anwendung) findet ebenso im Modell statt. Beispielsweise Zugriffe auf Datenbanken oder auch Kommunikation mit anderen Anwendungen. 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 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 Design 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 Modell auf technische oder optische Art und Weise repräsentieren. Verschiedene logische Sichtweisen bleiben dem Modell vorbehalten (bspw. verschiedene Benutzeransichten: Administrator, Normaluser).

Controller

Der Controller nimmt Eingaben aus verschiedensten Quellen entgegen und leitet diese standardisiert auf das Modell weiter. Er ist somit eine weitere Abstraktionsschicht, der Interaktionen des Benutzers mit der View wieder dem Modell zuführt.

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=14302“