Model-View-Controller-Paradigma

Dieser Artikel wird derzeit von einem Autor gründlich bearbeitet. Die Inhalte sind daher evtl. noch inkonsistent.

Dieser Artikel sollte überarbeitet werden.
Die Regeln für GlossarWiki-Artikel sollten beachten werden.
Die Aussagen sollten inhaltlich verbessert bzw. präzisiert werden.

In diesem Artikel sollten die Quellenangaben überarbeitet werden.
Bitte die Regeln der GlossarWiki-Quellenformatierung beachten.
Es sollten nicht nur Wikipedia-Artikel als Quelle verwendet werden.

Dieser Artikel ist nicht korrekt kategorisiert (siehe Regeln für GlossarWiki-Artikel).

Definition

MVC ist die Abkürzung für Model View Controller.

Das MVC-Paradigma bezeichnet ein Architekturmuster zur Trennung eines Programms in drei separate Einheiten: Datenmodell (Model), Präsentation (View) und Programmsteuerung (Controller). Vorteile dieses Paradigmas ist ein flexibles Programmdesign, welches Wiederverwendbarkeit der einzelnen Komponenten und reduzierte Komplexität gewährleistet, insbesondere bei großen Anwendungen.

Bemerkungen

Geschichte

In den Anfängen der Informatik war es nicht unüblich in 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.

Vorteile

Das MVC-Paradigma bietet eine Reihe von Vorteilen:

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

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

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

• allgemein: größere Softwareprojekte
• GUI-Programmierung (bspw. Frameworks wie Swing)
• Webanwendungen

Quellen

• Kowarschick, W. et al. (2005): Musterquelle (Buch)
• Goldratt, E.; Cox , J. (2004): The Goal
• Leach, L. (2005): Critical Chain Project Management

Auch externe Quellen können zitiert werden.

• Kowarschicks gesammelte Werke (besser als eigenes Quellen-Dokument, basierend auf der Vorlage:Quelle:URL)
• Wikipedia (so nicht, da zu allgemein und außerdem nicht der Wikipedia-Verweis benutzt wurde)
• Wikipedia:Vorlage (Datenverarbeitung) (sondern eher so, aber noch besser auch als eigenes Quellen-Dokument)

Siehe auch

Wikipedia:MVC