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

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg
Keine Bearbeitungszusammenfassung
Zeile 23: Zeile 23:
= Erweiterungen des MVC-Prozesses=
= Erweiterungen des MVC-Prozesses=
[[Medium:MVC-Prozess 02.png|gerahmt|rechts|MVC-Prozess 2 (mit erweiterter Interaktion)]]
[[Medium:MVC-Prozess 02.png|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-Seuerung, Verwendung von [[Webcam]] und Mikrofon oder Kommunikation über eine Daten-Schnittstelle (wie z.B. eine [[serielle Schnittstelle]] oder einen [[USB-Controller]]) möglich.  
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“).
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“).
Zeile 40: Zeile 40:


[[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)]]
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.  
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=
=Bemerkungen=

Version vom 26. Mai 2010, 16:13 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“).







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