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

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg
Wechseln zu:Navigation, Suche
(Initialisierung von Modulen)
(Das MVC-Pattern als 3-Tier-Layer-Pattern)
Zeile 40: Zeile 40:
 
## Wenn Modul B von einem Dritten als Empfänger angemeldet wird und Modul A alle notwendigen Informationen in den Multicast-Nachrichten mitschickt, braucht Modul B das Modul A nicht zu kennen.
 
## Wenn Modul B von einem Dritten als Empfänger angemeldet wird und Modul A alle notwendigen Informationen in den Multicast-Nachrichten mitschickt, braucht Modul B das Modul A nicht zu kennen.
  
=Das MVC-Pattern als 3-Tier-Layer-Pattern=
+
=Das MVC-Pattern als 3-Schickten-Pattern=
 +
[[Medium:MVC_Layer_Pattern_01.png|gerahmt||rechts|Das MVC-Pattern als Spezialfall des [[Layer-Pattern]]s]]
  
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 kann die drei MVC-Module in Schichten anordnen: Die unterste Schicht stellt das Modell dar, darüber liegt der Controller und zuoberst die View.
  
Man beachte, dass bei der Implementierung eines Modellmoduls weder die Steuerungs- noch die Darstellungsmodule bekannt sein müssen.
+
Das Layer- oder [[Layer-Pattern|Schichtenpattern]] erlaubt nur, dass höhere Schichten direket auf tiefere zugreifen, aber nicht umgekehrt.
 +
Ordnet man die drei MVC-Module so an, wie zuvor beschrieben, darf die View sowohl auf den Controller als auch auf das Modell zugreifen
 +
und der Controller auf das Modell. Das Modell darf dagegen auf kein anderes Modul direkt zugreifen.
 +
 +
Diese Schichteneinteilung ist sinnvoll. Wenn ein Modell, d.h. eine Abbildung eines Realitätsauschnitts auf ein Datenmodell, erstellt wird,
 +
ist weder festgelegt, wie die Manipulationen an diesem Modell realisiert werden, noch, auf welche Arten diese Daten den Benutzern
 +
präsentiert werden. Auch der Controller, der die Benutzereingaben verarbeitet, braucht nicht zu wissen, welche Views das Modell darstellen.
 +
Eine View dagegen muss das Modell kennen, dessen Daten sie visualisiert. Außerdem muss sie einen geeigneten
 +
Controller kennen, wenn sie Benutzeraktionen, wie z.B. Mausklicks auf bestimmte Buttons, verarbeiten lassen will.
  
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 Drei-Schichten-Architektur legt folgendes Kommunikationsverhalten nahe:
die Nachrichten nicht schon alle wesentlichen Änderungsdaten enthalten – um nähere Informationen über die aktuelle Änderung vom Sendermodell einholen zu können.
+
* Ein View-Objekt kommuniziert direkt mit den ihr zugeordneten Controller- und Modell-Objekten sowie evtl. mit anderen View-Objekten.
 +
* Ein Controller-Objekt kommuniziert direkt mit den ihr zugeorneten Modell-Objekten sowie evtl. mit anderen Controller-Objekten.
 +
* Ein Modell komminiziert höchsten mit anderen Modellobjekten direkt. Mit allen anderen Objekten kommuniziert sie nut per Multicast.
  
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.).
+
Auf diese Weise ist sichergestellt, dass zunächst alle Modell-Objekte erzeugt und initialisert werden können, da dafür keine
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,  
+
anderen Objekte bekannt sein müssen. Danach werden die Controller-Objekte erzeugt und initialisiert. Die Modell-Objekte,
da es mehere View-Module kann, aber meist nur ein Controller-Modul gibt. Bei der zweiten Variante müsste der Controller jedesmal
+
mit den die Controller kommunizieren, existieren zu diesem Zeitpunkt schon. Zu guter Letzt werden die View-Objekte erzeugt und initialisiert.
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 zweite Möglichkeit wäre, dass alle Objekte per Multicast-Nachrichten kommunizieren. Allerdings müssten die Empfänger-Objekte jeweils von
 
+
dritter Stelle, das heißt vom Initialisierungs-Modul, beim Sender registriert werden. Außerdem müssten in den Multicast-Nachrichten alle
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.
+
wesentlichen Informationen mitgeschickt werden. Anderenfall müsste beispielsweise ein Modell-Objekt alle Controller kennen,  
 
+
die mit diesen Modell-Objekt kommunizieren wollen: Entweder, um sich
 
+
als Nachrichtenempfänger bei „seinen“ Controllern zu regisrieren, oder, um, im Falle von Nachrichten vom Controller, nähere Informationen 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.).
+
welche Änderungen am Modell vorgenommen werden sollen.
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=
 
=Quellen=

Version vom 11. April 2011, 08:30 Uhr

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.

1 Definition

Ein Model-View-Controller-Pattern, kurz MVC-Pattern, bezeichnet ein Entwurfsmuster, 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.

2 Verschiedene Realisierungsmöglichkeiten

Es gibt mehrere Möglichkeiten, geeignete Klassen- und Objekt-Strukturen zu definieren, d.h. es gibt mehrere MVC-Pattern-Varianten.

Zwei wichtige Aspekte, die dabei berücksichtigt werden müssen, sind die

  • Initilaisierun: Wie werden die Module initialisiert?
  • Kommunikation: Auf welche Arten kommunizieren die Module miteinander?

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

3 Kommunikation zwischen MVC-Modulen

gerahmt|rechts|MVC-Prozess: Verschiedene Arten der 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 zwei Modulen gibt es mehrere Möglichkeiten. Die wichtigsten davon sind

  1. Unicast-Nachrichten: Modul A ruft Methoden von Modul B direkt auf.
  2. Multicast-Nachrichten: Modul A informiert alle Module, die als Nachrichtenempfänger angemeldet wurden, mit Hilfe von Signalen (Observer-Pattern)
    1. Der Sender informiert mit einer 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 danach nicht mehr auf den Sender zugreifen muss.

4 Initialisierung von Modulen

Je nach Art der Kommunikation müssen die verschiedenen Module unterschiedlich initialisiert werden:

  1. Unicast-Nachrichten: Modul A muss das Modul B kennen, bevor es mit diesem Modul kommunizieren kann
  2. Multicast-Nachrichten: Modul B muss sich bei Modul A als Empfänger anmelden oder es muss von dritter Seite angemeldet werden, bevor es Nachrichten von A empfängt.
    1. Modul B muss Modul A kennen, wenn Modul B sich sebst als Empfänger bei Modul A anmelden muss oder wenn Modul B nach Empfang einer Nachricht weitere Informationen von Modul A erfragen muss.
    2. Wenn Modul B von einem Dritten als Empfänger angemeldet wird und Modul A alle notwendigen Informationen in den Multicast-Nachrichten mitschickt, braucht Modul B das Modul A nicht zu kennen.

5 Das MVC-Pattern als 3-Schickten-Pattern

[[Medium:MVC_Layer_Pattern_01.png|gerahmt||rechts|Das MVC-Pattern als Spezialfall des Layer-Patterns]]

Man kann die drei MVC-Module in Schichten anordnen: Die unterste Schicht stellt das Modell dar, darüber liegt der Controller und zuoberst die View.

Das Layer- oder Schichtenpattern erlaubt nur, dass höhere Schichten direket auf tiefere zugreifen, aber nicht umgekehrt. Ordnet man die drei MVC-Module so an, wie zuvor beschrieben, darf die View sowohl auf den Controller als auch auf das Modell zugreifen und der Controller auf das Modell. Das Modell darf dagegen auf kein anderes Modul direkt zugreifen.

Diese Schichteneinteilung ist sinnvoll. Wenn ein Modell, d.h. eine Abbildung eines Realitätsauschnitts auf ein Datenmodell, erstellt wird, ist weder festgelegt, wie die Manipulationen an diesem Modell realisiert werden, noch, auf welche Arten diese Daten den Benutzern präsentiert werden. Auch der Controller, der die Benutzereingaben verarbeitet, braucht nicht zu wissen, welche Views das Modell darstellen. Eine View dagegen muss das Modell kennen, dessen Daten sie visualisiert. Außerdem muss sie einen geeigneten Controller kennen, wenn sie Benutzeraktionen, wie z.B. Mausklicks auf bestimmte Buttons, verarbeiten lassen will.

Die Drei-Schichten-Architektur legt folgendes Kommunikationsverhalten nahe:

  • Ein View-Objekt kommuniziert direkt mit den ihr zugeordneten Controller- und Modell-Objekten sowie evtl. mit anderen View-Objekten.
  • Ein Controller-Objekt kommuniziert direkt mit den ihr zugeorneten Modell-Objekten sowie evtl. mit anderen Controller-Objekten.
  • Ein Modell komminiziert höchsten mit anderen Modellobjekten direkt. Mit allen anderen Objekten kommuniziert sie nut per Multicast.

Auf diese Weise ist sichergestellt, dass zunächst alle Modell-Objekte erzeugt und initialisert werden können, da dafür keine anderen Objekte bekannt sein müssen. Danach werden die Controller-Objekte erzeugt und initialisiert. Die Modell-Objekte, mit den die Controller kommunizieren, existieren zu diesem Zeitpunkt schon. Zu guter Letzt werden die View-Objekte erzeugt und initialisiert.

Ein zweite Möglichkeit wäre, dass alle Objekte per Multicast-Nachrichten kommunizieren. Allerdings müssten die Empfänger-Objekte jeweils von dritter Stelle, das heißt vom Initialisierungs-Modul, beim Sender registriert werden. Außerdem müssten in den Multicast-Nachrichten alle wesentlichen Informationen mitgeschickt werden. Anderenfall müsste beispielsweise ein Modell-Objekt alle Controller kennen, die mit diesen Modell-Objekt kommunizieren wollen: Entweder, um sich als Nachrichtenempfänger bei „seinen“ Controllern zu regisrieren, oder, um, im Falle von Nachrichten vom Controller, nähere Informationen einholen zu können, welche Änderungen am Modell vorgenommen werden sollen.

6 Quellen

7 Siehe auch


Dieser Artikel ist GlossarWiki-konform.