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

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg
Wechseln zu:Navigation, Suche
(Anwendungsgebiete)
(Siehe auch)
Zeile 63: Zeile 63:
 
*[http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html Reenskaugs eigene Seite über MVC ]
 
*[http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html Reenskaugs eigene Seite über MVC ]
 
*[[Wikipedia:MVC]]
 
*[[Wikipedia:MVC]]
 +
* http://trac.puremvc.org/PureMVC
  
 
[[en:GlossaryWiki:MVC]]
 
[[en:GlossaryWiki:MVC]]

Version vom 18. November 2008, 14:53 Uhr

1 Definition

Das Model-View-Controller-Paradigma oder -Pattern, kurz MVC, bezeichnet ein Architekturmuster zur Trennung eines Programms in drei separate Einheiten: Datenmodell (Model), Präsentation (View) und Programmsteuerung (Controller).

2 Bemerkungen

2.1 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 70ern und später die objektorientierte Programmierung in den 80ern 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.

Eine Variante ist MVC2 (MVC Model 2 bzw. MVC Version 2), die speziell für Webanwendungen gedacht ist.

2.2 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:

  • Gut strukturiertes Design durch klare Trennung der Anwendungslogik von den dazugehörenden Daten und der Benutzerinteraktion.
  • Änderungen an einer Komponente sind möglich, ohne dass andere Komponenten davon betroffen werden; sogar ganze Komponenten können ausgetauscht werden.
  • Mehrere Ansichten des Systems können durch Austausch verschiedener Views realisiert werden.
  • Im Fehlerfall ist die Suche nach dem Fehler in der Regel auf eine Komponente beschränkt.
  • Erweiterbarkeit bestehender Systeme, indem neue Komponenten hinzugefügt werden. Alte Komponenten können aus Kompatibilitätsgründen erhalten bleiben.

Insgesamt sind Programmcode und Komponenten übersichtlicherer und einfacher zu warten, zu ändern und auszutauschen.

2.3 Nachteile

Auch wenn die Vorteile überwiegen, gibt es dennoch ein paar Nachteile:

  • Bei der Planung und Implementierung ist wesentlich mehr Gründlichkeit erforderlich.
  • Erheblicher Mehraufwand bei kleinen Applikationen. Dieser Aufwand rechtfertigt andere Programmweisen.

2.4 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:

2.4.1 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.

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

2.4.3 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.

2.5 Anwendungsgebiete

3 Quellen

4 Siehe auch


Dieser Artikel ist GlossarWiki-konform.