Muster: ModelViewController

Aus Wikibooks
Zur Navigation springen Zur Suche springen
Wikibooks buchseite.svg Zurück zu Kompositum | One wikibook.svg Hoch zu Inhaltsverzeichnis | Wikibooks buchseite.svg Vor zu Nullobjekt

Vorwort[Bearbeiten]

Dieses Entwurfsmuster realisiert die Trennung zwischen Daten (Model), Darstellung (View) und Programmlogik (Funktionalität, business logic) (Controller). Es ist umstritten, ob es ein Entwurfsmuster oder ein Muster der höheren Kategorie, sprich ein Architekturmuster ist.

Voraussetzungen[Bearbeiten]

  • Verständnis der Grundprinzipien objektorientierten Designs und objektorientierter Konzepte, insbesondere Kapselung.
  • Verständnis des Beobachter-Musters.

Beispiel für einen Anwendungsfall[Bearbeiten]

Wir betrachten die Implementierung einer Anwendung, mit der das Betrachten von Aktienkursen (das heißt, deren Zahlenform) möglich ist. Die Kursdaten stammen von einem Server im Netz, mit dem das Programm kommuniziert.

Pflichtenheft[Bearbeiten]

Folgendes soll die Anwendung tun:

  • Den Kurs der ausgewählten Aktie holen und anzeigen; ändert sich die Auswahl, so soll der Kurs der neuen Aktie geladen werden.
  • Immer wieder nach einem gewissen Intervall (z.B. 30 Sekunden) soll der Kurs aktualisiert, also der aktuelle vom Server geholt werden.

Design[Bearbeiten]

Es ist durchaus möglich, die Anwendung in einem Programmstück zu schreiben; nur ist es designtechnisch nicht so schön, insbesondere nicht so flexibel. Desweiteren ließe sich das Programm eigentlich gut aufteilen:

  • Daten
    • Der aktuelle Kurs der Aktie, z.B. eine Zahl.
  • Präsentation
    • Die Präsentation des Kurses, ein Element der Benutzeroberfläche.
    • Das Auswahlfeld zur Auswahl der zu betrachtenden Aktie, ein Element der Benutzeroberfläche.
  • Programmlogik
    • Der Programmteil, der den Kurs holt, z.B. als Programmbibliothek.
    • Der Programmteil, der in bestimmten Intervallen den Kurs aktualisiert, als eigener Thread.

Dieses Design trennt das Programm in einzelne, einfacher zu überschauende Teile. Das Design verwendet dabei das Model-View-Controller-Muster.

Prinzipien[Bearbeiten]

Model-View-Controller trennt eine Anwendung in diese drei Teile auf:

Model
Daten. Die Daten an sich, mit begrenzten Informationen bezüglich ihrer Darstellung.
View
Präsentation der Daten. Abhängig vom Model und von den Controllern (sofern vorhanden).
Controller
Management der Daten. Abhängig vom Model, jedoch nicht von den Views.

Meist wird für das Zusammenspiel von Model und Views das Beobachter-Muster verwendet, mit den Views als Beobachter des Models.

Daher ergeben sich typische Abläufe in Programmen mit MVC:

  • Ein View kann den Controller veranlassen, Dinge zu tun.
  • Der Controller kann das Model aktualisieren.
  • Das aktualisierte Model kann seine Beobachter, also die Views, dazu veranlassen, sich zu aktualisieren.

Das Beispiel wurde bereits nach dem MVC-Schema aufgeteilt. In diesem Fall wird dadurch folgendes passieren können:

  • Das Aktienauswahlfeld (Teil des View) gibt bei einer Auswahländerung dem Controller den Auftrag, den Kurs der neuen Aktie zu laden.
  • Der Thread, der die automatische Aktualisierung verwaltet, gibt in regelmäßigen Abständen dem Controller den Auftrag, den Kurs der gerade gewählten Aktie zu laden.
  • Der Controller kommuniziert mit den Server und schreibt letztendlich den neuen Kurs in das Objekt mit der Variable mit dem aktuellen Kurs (Model).
  • Immer wenn sich das Model ändert, benachrichtigt es alle seine Beobachter (in diesem Fall die Präsentation des Kurses, Teil des View), so dass sich diese dann aktualisieren, also den neuen Wert anzeigen.

Vorteile[Bearbeiten]

  • Ein Model kann ohne weiteres mehrere Views unterstützen, sofern sie das Beobachter-Muster verwenden.
  • Ein Model kann ohne weiteres mehrere Controller unterstützen. Das wird insbesondere mit mehreren Views dahingehend verwendet, dass ein Model eine Zahl von View-Controller-Paaren besitzen kann. (Insbesondere kann auch Wikibooks, in Verbindung mit Webbrowsern, als eine Anwendung dieser Art gesehen werden - auch wenn die Komponenten hier über mehrere Rechner verteilt sind.)
  • Die Komponenten lassen sich beliebig verändern - sofern ihre Schnittstellen gleich bleiben, ist keine Anpassung der anderen Komponenten notwendig.

Nachteile[Bearbeiten]

  • Für kleinere Anwendungen ergibt sicht oftmals nicht unerheblicher Overhead
  • Eine klare, eindeutige Trennung zwischen den Schichten ist oft nicht möglich.

Anwendungen[Bearbeiten]

Das Entwurfsmuster wird generell häufig eingesetzt, vorallen aufgrund seiner Flexibilität. Einzelne Komponenten können leicht verändert oder sogar ausgetauscht werden, ohne dass die anderen Komponenten davon betroffen sind, solange das Interface identisch bleibt. Dies erlaubt zum Beispiel den Wechsel zwischen verschiedenen Datenbanksystemen durch Manipulation des Models, oder die Möglichkeit Ausgaben für verschiedene Medien zu generieren durch Austausch der View-Schicht.

Weblinks[Bearbeiten]

Wikipedia: Model View Controller

Hoch zum Inhaltsverzeichnis Hoch zum Inhaltsverzeichnis