Model-View-Controller-Pattern

Dieser Artikel erfüllt die GlossarWiki-Qualitätsanforderungen nur teilweise:

Korrektheit: 4 (großteils überprüft)

Umfang: 3 (einige wichtige Fakten fehlen)

Quellenangaben: 4 (fast vollständig vorhanden)

Quellenarten: 4 (sehr gut)

Konformität: 4 (sehr gut)

Diese Bewertungen beziehen sich auf alle im nachfolgenden Menü genannten Artikel gleichermaßen.

Definition

Ein Model-View-Controller-Pattern, kurz MVC-Pattern, bezeichnet ein Entwurfmuster, das auf dem Model-View-Controller-Paradigma beruht, das also für die MVC-Module Model, View und Controller geeignete Klassen- und Objekt-Strukturen definiert.

Bemerkung

Es gibt mehrere Arten von MVC-Patterns, die sich hinsichtlich Klassen- und Objektstruktur unterscheiden.

Verschiedene Realisierungsmöglichkeiten

Es gibt mehrere Möglichkeiten für das MVC-Pattern geeignete Klassen-Templtes zu definieren. Zwei wichtige Aspekte, die dabei berücksichtigt werden müssen, sind die

• Initialiserung der Module
• Kommunikation zwischen den Modulen

Basierend auf diesen Vorüberlegungen sollen drei mögliche MVC-Pattern vorgestellt werden:

• Initialiserung mittels Depenceny Injection
• Initialiserung mittels Singleton(s)
• Kommunikation ausschließlich mittels des Observer Patterns

Kommunikation zwischen den MVC-Modulen

gerahmt|rechts|MVC-Prozess: Kommunikation Ein wichtiges Programmierprinzip ist es, so wenige Abhängigkeiten wie möglich zu erzeugen (few interfaces), da Abhängigkeiten die Komplexität und die Fehleranfälligkeit erhöhen. Die Abhängigkeiten entstehen dadurch, dass die MVC-Module miteinander kommunizieren müssen.

Für die Kommunikation zwischen den drei MVC-Modulen „Model“, „View“ und „Controller“ gibt es mehrere Möglichkeiten:

1. Ein Modul hat direkten Zugriffe auf ein zweites (durchgezogene Linie im Diagramm „MVC-Prozess 2b“).
2. Ein Modul (Sender) informiert beliebig viele andere Module (Empfänger) mit Hilfe von Multicast-Nachrichten (Observer-Pattern, gestrichelte Linie im Diagramm „MVC-Prozess 2b“).
   1. Der Sender informiert mit der Nachricht die Empfänger lediglich, dass sich etwas geändert hat. Die Empfänger müssen sich daraufhin die für sie wichtigen Information per direktem Zugriff vom Sender holen.
   2. Der Sender schickt in der Nachricht detailierte Informationen mit, so dass der Empfänger nicht noch einmal auf den Sender zugreifen muss.

Ein Modellmodul sollte vollkommen unabhängig von anderen Modulen existieren. Es stellt lediglich Methoden zur Verfügung, mit deren Hilfe irgendwelche Steuerungsmodule die Daten des Modells manipulieren können. Mit Hilfe von Mulitcast-Nachrichten informiert ein Modell die übrigen Module über erfolgte Änderungen. Dabei muss sich der Programmierer entscheiden, ob mit einer derartigen Nachricht detailierte Informationen über die Änderungen mitgeschickt werden (2.2) oder nicht (2.1).

Man beachte, dass bei der Implementierung eines Modellmoduls weder die Steuerungs- noch die Darstellungsmodule bekannt sein müssen.

Ein Darstellungmodul lauscht auf Nachrichten einer oderer mehrerer Modellmodule. Es muss diese Modelle kennen, wenn es sich dort selbst zum Nachrichten-Empfang anmelden muss und/oder – sofern die Nachrichten nicht schon alle wesentlichen Änderungsdaten enthalten – um nähere Informationen über die aktuelle Änderung vom Sendermodell einholen zu können.

Interaktive Darstellungsmodulen müssen außerdem die zugehörigen Steuerungsmodule über User-Aktionen informieren. Dies kann entweder direkt (1.) oder mit Hilfe von Multicast-Nachrichten erfolgen (2.). Im ersten Fall müssen das Darstellungsmodule die zugehörigen Steuerungsmodule kennen, damit sie diese direkt informieren können. Im zweiten Fall müssen dagegen die Steuerungsmodule die zugehörigen Darstellungsmodule kennen, bei denen sie sich als Empfänger anmelden und gegebenfalls Detail-Informationen zu bestimmten Änderungen erfragen. Im Allgemeinen sollte der ersten Variante der Vorzug gegeben werden, da es mehere View-Module kann, aber meist nur ein Controller-Modul gibt. Bei der zweiten Variante müsste der Controller jedesmal angepasst werden, wenn sich die Anzahl der View verändert.

Aus Gründen der Modularität sollten diejenigen Darstellungsmodule, die lediglich Modelldaten visualisieren, und die Darstellungsmodule mit interaktiven Elementen möglichst getrennt realisiert werden.

Ein Steuerungsmodul schließlich manipuliert ein oder mehrere Modellmodule. Dies sollte stets per direktem Zugriff erfolgen, damit die Modellfunktionalität nicht von der Existenz spezieller Steuerungsmodule abhängt.

Quellen

• Kowarschick, W.: Multimedia-Programmierung
• Gamma et al. (1995)

Siehe auch

• Model-View-Controller-Paradigma

Dieser Artikel ist GlossarWiki-konform.