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

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg
Wechseln zu:Navigation, Suche
(Heterogen: Unicast- und Multicast-Kommunikation)
 
(18 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
 
{{MVC:Menü}}
 
{{MVC:Menü}}
=Definition=
+
==Definition==
 
Ein [[Model-View-Controller-Pattern]], kurz [[MVC-Pattern]], bezeichnet ein [[Entwurfsmuster]], das  
 
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  
 
auf dem [[Model-View-Controller-Paradigma]] beruht, das also für die MVC-Module  
 
[[Model-View-Controller-Paradigma/Model|Model]], [[Model-View-Controller-Paradigma/View|View]] und [[Model-View-Controller-Paradigma/Controller|Controller]]  
 
[[Model-View-Controller-Paradigma/Model|Model]], [[Model-View-Controller-Paradigma/View|View]] und [[Model-View-Controller-Paradigma/Controller|Controller]]  
geeignete [[Klassen]]- und [[Objekt]]-Strukturen definiert.
+
geeignete [[Klasse (OOP)|Klassen]]- und [[Objekt (OOP)|Objekt]]-Strukturen definiert.
  
=Verschiedene Realisierungsmöglichkeiten=
+
==Verschiedene Realisierungsmöglichkeiten==
  
 
Es gibt mehrere Möglichkeiten, geeignete Klassen- und Objekt-Strukturen zu definieren,
 
Es gibt mehrere Möglichkeiten, geeignete Klassen- und Objekt-Strukturen zu definieren,
d.h. es gibt mehrere MVC-Pattern-Varianten.
+
{{dh}}, es gibt mehrere MVC-Pattern-Varianten.
  
 
Zwei wichtige Aspekte, die dabei berücksichtigt werden müssen, sind die
 
Zwei wichtige Aspekte, die dabei berücksichtigt werden müssen, sind die
Zeile 20: Zeile 20:
 
* [[Model-View-Controller-Pattern/Observer|Kommunikation ausschließlich mittels des Observer Patterns]] (empfehlenswert)
 
* [[Model-View-Controller-Pattern/Observer|Kommunikation ausschließlich mittels des Observer Patterns]] (empfehlenswert)
  
=Kommunikation zwischen MVC-Modulen=
+
==Kommunikation zwischen MVC-Modulen==
[[Medium:MVC-Prozess 02b.png|gerahmt|rechts|MVC-Prozess: Verschiedene Arten der Kommunikation]]
+
[[Datei:VCM-Prozess 01.png|gerahmt|rechts|VCM-Prozess]]
 
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.
 
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.  
 
Die Abhängigkeiten entstehen dadurch, dass die MVC-Module miteinander kommunizieren müssen.  
Zeile 27: Zeile 27:
 
Für die Kommunikation zwischen zwei Modulen gibt es mehrere Möglichkeiten. Die wichtigsten davon sind:
 
Für die Kommunikation zwischen zwei Modulen gibt es mehrere Möglichkeiten. Die wichtigsten davon sind:
 
# [[Unicast-Nachricht]]en: Modul A ruft Methoden von Modul B direkt auf.
 
# [[Unicast-Nachricht]]en: Modul A ruft Methoden von Modul B direkt auf.
# [[Multicast-Nachricht]]en: Modul A informiert alle Module, die als Nachrichtenempfänger angemeldet wurden, mit Hilfe von [[Signal]]en ([[Observer-Pattern]])
+
# [[Multicast-Nachricht]]en: Modul A informiert alle Module, die als Nachrichtenempfänger angemeldet wurden, mit Hilfe von [[Signal]]en ([[Observer-Pattern]]).
## 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.
+
## 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 Informationen per direktem Zugriff vom Sender holen.
 
## Der Sender schickt in der Nachricht detailierte Informationen mit, so dass der Empfänger danach nicht mehr auf den Sender zugreifen muss.
 
## Der Sender schickt in der Nachricht detailierte Informationen mit, so dass der Empfänger danach nicht mehr auf den Sender zugreifen muss.
  
Weitere Kommunikationsmöglichkeiten, wie z.B. [[Broadcast-Nachricht]]en,  die Kommunikation über globale Variablen (insbesondere [[Klassenattribute]] etc. sollten i. Allg. vermieden werden. Bei Broadcast-Nachrichten, die an eine Vielzahl von nicht-beteiligten Objekten gehen, muss jeder
+
Weitere Kommunikationsmöglichkeiten, wie {{zB}} [[Broadcast-Nachricht]]en,  die Kommunikation über globale Variablen (insbesondere über [[Klassenattribute]]) etc., sollten {{iAllg}} vermieden werden.  
einzelne Empfäger entscheiden, ob die jweils empfnagene NAchricht für ihn überhaupt von Interesse ist.  
+
Bei Broadcast-Nachrichten, die an eine Vielzahl von nicht-beteiligten Objekten gehen, muss jeder
Bei globalen Variablen kann i. Allg. nur schwer nachvollzogen werden, wer welche Variablen zu Kommunikation nutzt oder ob bestimmte Variablen überhaupt noch zur Kommunikation benötigt werden. Der zugehörige Code wird im Laufe der Zeit im unwartbarer.
+
einzelne Empfäger entscheiden, ob die jweils empfangene Nachricht für ihn überhaupt von Interesse ist.  
 +
Bei globalen Variablen kann {{iAllg}} nur schwer nachvollzogen werden, wer welche Variablen zu Kommunikation nutzt oder ob bestimmte Variablen überhaupt noch zur Kommunikation benötigt werden. Der zugehörige Code wird im Laufe der Zeit im unwartbarer.
  
=Initialisierung von MVC-Modulen=
+
==Initialisierung von MVC-Modulen==
  
 
Je nach Art der Kommunikation müssen die verschiedenen Module unterschiedlich initialisiert werden:
 
Je nach Art der Kommunikation müssen die verschiedenen Module unterschiedlich initialisiert werden:
Zeile 44: Zeile 45:
 
## 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-Schichten-Pattern=  
+
==Das MVC-Pattern als 3-Schichten-Pattern==  
[[Medium:MVC_Layer_Pattern_01.png|gerahmt||rechts|Das MVC-Pattern als Spezialfall des [[Layer-Pattern]]s]]
+
[[Datei:VCM-Schichtenarchitektur 01.png|gerahmt||rechts|Das MVC-Pattern als Spezialfall des [[Layer-Pattern]]s]]
  
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 kann die drei MVC-Module in Schichten anordnen: In der untersten Schicht ist das Modell angesiedelt, darüber liegt der Controller
 +
und zuoberst die View.
  
 
Das Layer- oder [[Layer-Pattern|Schichtenpattern]] erlaubt nur, dass höhere Schichten direkt auf tiefere zugreifen, aber nicht umgekehrt.
 
Das Layer- oder [[Layer-Pattern|Schichtenpattern]] erlaubt nur, dass höhere Schichten direkt auf tiefere zugreifen, aber nicht umgekehrt.
Zeile 53: Zeile 55:
 
und der Controller auf das Modell. Das Modell darf dagegen auf kein anderes Modul direkt 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,
+
Diese Schichteneinteilung ist sinnvoll. Wenn ein Modell, {{dh}} 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
 
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.  
 
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
 
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.   
+
Controller kennen, wenn sie Benutzeraktionen, wie {{zB}} Mausklicks auf bestimmte Buttons, verarbeiten lassen will.   
  
==Heterogene Kommunikationswelt: Unicast- und Multicast-Kommunikation==
+
===Heterogene Kommunikationswelt: Unicast- und Multicast-Kommunikation===
  
 
Die Drei-Schichten-Architektur legt folgendes Kommunikationsverhalten nahe:
 
Die Drei-Schichten-Architektur legt folgendes Kommunikationsverhalten nahe:
Zeile 70: Zeile 72:
 
mit den die Controller kommunizieren, existieren zu diesem Zeitpunkt schon. Zu guter Letzt werden die View-Objekte erzeugt und initialisiert.
 
mit den die Controller kommunizieren, existieren zu diesem Zeitpunkt schon. Zu guter Letzt werden die View-Objekte erzeugt und initialisiert.
  
==Homogen: Nur Multicast-Kommunikation==
+
===Homogene Kommunikationswelt: Reine Multicast-Kommunikation===
  
Ein zweite Möglichkeit wäre, dass alle Objekte per Multicast-Nachrichten kommunizieren. Allerdings müssten die Empfänger-Objekte jeweils von
+
Ein zweite Möglichkeit wäre, alle Objekte per Multicast-Nachrichten kommunizieren zu lassen. Allerdings sollten in diesem Fall
dritter Stelle, das heißt vom Initialisierungs-Modul, beim Sender registriert werden. Außerdem müssten in den Multicast-Nachrichten alle  
+
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. Anderenfalls müsste beispielsweise ein Modell-Objekt alle Controller kennen,  
 
wesentlichen Informationen mitgeschickt werden. Anderenfalls müsste beispielsweise ein Modell-Objekt alle Controller kennen,  
 
die mit diesen Modell-Objekt kommunizieren wollen: Entweder, um sich
 
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,  
+
als Nachrichtenempfänger bei „seinen“ Controllern zu regisrieren, oder, um, sobald Nachrichten vom Controller eintreffen,
welche Änderungen am Modell vorgenommen werden sollen.
+
nähere Informationen vom Controller einholen zu können, welche Änderungen am Modell eigentlich vorgenommen werden sollen.
  
=3 verschiedene Arten von MVCS-Pattern=
+
==Drei verschiedene Arten von MVCS-Pattern==
  
==Initialisierung mittels Dependency Injection==
+
===Initialisierung mittels Singleton(s)===
 +
Bei [[Model-View-Controller-Pattern/Singleton|diesem Pattern]] 
 +
kommunizeren ebenfalls nur die Modell-Objekte mittels Multicast-Nachrichten. Die
 +
anderen Objekte kommunizieren mittels Unicast-Nachrichten.
 +
 
 +
Initialisiert werden alle Module mittels Zugriffen auf ein oder mehrere [[Singelton-Pattern|Singleton-Klassen]]. 
 +
 
 +
Der Nachteil dieses Patterns ist, dass die Singleton-Klassen wie globale Variablen wirken. Daher sollte
 +
auf diese Art der Realisierung im Allgemeinen verzichtet werden.
 +
 
 +
Details siehe: [[Model-View-Controller-Pattern/Singleton|DMVC-Pattern: Initialisierung mittels Singleton(s)]]
 +
 
 +
===Initialisierung mittels Dependency Injection===
 
Bei [[Model-View-Controller-Pattern/Dependency Injection|diesem Pattern]]   
 
Bei [[Model-View-Controller-Pattern/Dependency Injection|diesem Pattern]]   
 
kommunizeren nur die Modell-Objekte mittels Multicast-Nachrichten. Die  
 
kommunizeren nur die Modell-Objekte mittels Multicast-Nachrichten. Die  
Zeile 87: Zeile 102:
  
 
Initialisiert werden alle Module mittels [[Dependency Injection]].   
 
Initialisiert werden alle Module mittels [[Dependency Injection]].   
 +
 +
Der Nachteil dieses Patterns ist, dass View- und Controller-Module ihre Kommunikationspartner kennen müssen.
 +
Dies widerspricht dem [[Programmierprinzip]], die Schnittstellen möglichst klein zu halten (small interfaces).
 +
Allerdings kann man dieses Problem abmildern, wenn man für jeden Kommunikationskanal eigene,
 +
möglichst schlanke Kommunikationsschnittstellen definiert.
  
 
Details siehe: [[Model-View-Controller-Pattern/Dependency Injection|MVC-Pattern: Initialisierung mittels Dependency Injection]]  
 
Details siehe: [[Model-View-Controller-Pattern/Dependency Injection|MVC-Pattern: Initialisierung mittels Dependency Injection]]  
  
==Initialisierung mittels Singleton(s)==
+
===Kommunikation ausschließlich mittels des Observer-Patterns===
Bei [[Model-View-Controller-Pattern/Singleton|diesem Pattern]] 
 
kommunizeren ebenfalls nur die Modell-Objekte mittels Multicast-Nachrichten. Die
 
anderen Objekte kommunizieren mittels Unicast-Nachrichten.
 
 
 
Initialisiert werden alle Module mittels Zugriffen auf ein oder mehrere [[Singelton-Pattern|Singleton-Klassen]]. 
 
 
 
Details siehe: [[Model-View-Controller-Pattern/Singleton|DMVC-Pattern: Initialisierung mittels Singleton(s)]]
 
 
 
==Kommunikation ausschließlich mittels des Observer Patterns==
 
 
Bei [[Model-View-Controller-Pattern/Observer|diesem Pattern]]   
 
Bei [[Model-View-Controller-Pattern/Observer|diesem Pattern]]   
 
kommunizeren alle MVC-Objekte mittels Multicast-Nachrichten (die alle notwendigen Informationen
 
kommunizeren alle MVC-Objekte mittels Multicast-Nachrichten (die alle notwendigen Informationen
Zeile 106: Zeile 117:
 
Die Zuweisung der Nachrichten-Sender zu ihren Nachrichten-Empfängern erfolgt während der Initialisierungsphase
 
Die Zuweisung der Nachrichten-Sender zu ihren Nachrichten-Empfängern erfolgt während der Initialisierungsphase
 
von außerhalb. Das heißt, die einzelnen MVC-Objekte kennen einander nicht.
 
von außerhalb. Das heißt, die einzelnen MVC-Objekte kennen einander nicht.
 +
 +
Der Nachteil dieses Patterns ist, dass die eine Multicast-Kommunikation weniger effizient ist, als eine Unicast-Kommunikation.
 +
In zeitkritischen Anwendungen kann dies evtl. zu Problemen führen.
  
 
Details siehe: [[Model-View-Controller-Pattern/Observer|MVC-Pattern: Kommunikation ausschließlich mittels des Observer Patterns]]
 
Details siehe: [[Model-View-Controller-Pattern/Observer|MVC-Pattern: Kommunikation ausschließlich mittels des Observer Patterns]]
  
=Quellen=
+
==Quellen==
<noinclude>
+
<ol>
* [[Kowarschick, W.: Multimedia-Programmierung]]</noinclude>
+
<li>{{Quelle|Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. (1995): Design Patterns}}</li>
* [[Gamma et al. (1995)]]
+
<li>{{Quelle|Kowarschick, W.: Multimedia-Programmierung}}</li>
 +
</ol>
  
=Siehe auch=
+
==Siehe auch==
 
*[[Model-View-Controller-Paradigma]]
 
*[[Model-View-Controller-Paradigma]]
<noinclude>[[Kategorie:Objektorientierte Programmierung]]
+
<noinclude>
[[Kategorie:Glossar]][[Kategorie:MVC]]
+
[[Kategorie:MVC]]
 +
[[Kategorie:Objektorientierte Programmierung]]
 +
[[Kategorie:Glossar]]
 
[[en:MVC]]
 
[[en:MVC]]
 
[[Kategorie:Kapitel:Multimedia-Programmierung]]
 
[[Kategorie:Kapitel:Multimedia-Programmierung]]
{{{{SITENAME}}-konformer Artikel}}</noinclude>
+
</noinclude>

Aktuelle Version vom 22. September 2017, 15:50 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

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

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

3 Kommunikation zwischen MVC-Modulen

VCM-Prozess

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

Weitere Kommunikationsmöglichkeiten, wie z. B. Broadcast-Nachrichten, die Kommunikation über globale Variablen (insbesondere über Klassenattribute) etc., sollten i. Allg. vermieden werden. Bei Broadcast-Nachrichten, die an eine Vielzahl von nicht-beteiligten Objekten gehen, muss jeder einzelne Empfäger entscheiden, ob die jweils empfangene Nachricht für ihn überhaupt von Interesse ist. Bei globalen Variablen kann i. Allg. nur schwer nachvollzogen werden, wer welche Variablen zu Kommunikation nutzt oder ob bestimmte Variablen überhaupt noch zur Kommunikation benötigt werden. Der zugehörige Code wird im Laufe der Zeit im unwartbarer.

4 Initialisierung von MVC-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-Schichten-Pattern

Das MVC-Pattern als Spezialfall des Layer-Patterns

Man kann die drei MVC-Module in Schichten anordnen: In der untersten Schicht ist das Modell angesiedelt, darüber liegt der Controller und zuoberst die View.

Das Layer- oder Schichtenpattern erlaubt nur, dass höhere Schichten direkt 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.

5.1 Heterogene Kommunikationswelt: Unicast- und Multicast-Kommunikation

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 zugeordneten Modell-Objekten sowie evtl. mit anderen Controller-Objekten.
  • Ein Modell komminiziert höchstens mit anderen Modellobjekten direkt. Mit allen anderen Objekten kommuniziert sie nur 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.

5.2 Homogene Kommunikationswelt: Reine Multicast-Kommunikation

Ein zweite Möglichkeit wäre, alle Objekte per Multicast-Nachrichten kommunizieren zu lassen. Allerdings sollten in diesem Fall 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. Anderenfalls 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, sobald Nachrichten vom Controller eintreffen, nähere Informationen vom Controller einholen zu können, welche Änderungen am Modell eigentlich vorgenommen werden sollen.

6 Drei verschiedene Arten von MVCS-Pattern

6.1 Initialisierung mittels Singleton(s)

Bei diesem Pattern kommunizeren ebenfalls nur die Modell-Objekte mittels Multicast-Nachrichten. Die anderen Objekte kommunizieren mittels Unicast-Nachrichten.

Initialisiert werden alle Module mittels Zugriffen auf ein oder mehrere Singleton-Klassen.

Der Nachteil dieses Patterns ist, dass die Singleton-Klassen wie globale Variablen wirken. Daher sollte auf diese Art der Realisierung im Allgemeinen verzichtet werden.

Details siehe: DMVC-Pattern: Initialisierung mittels Singleton(s)

6.2 Initialisierung mittels Dependency Injection

Bei diesem Pattern kommunizeren nur die Modell-Objekte mittels Multicast-Nachrichten. Die anderen Objekte kommunizieren mittels Unicast-Nachrichten.

Initialisiert werden alle Module mittels Dependency Injection.

Der Nachteil dieses Patterns ist, dass View- und Controller-Module ihre Kommunikationspartner kennen müssen. Dies widerspricht dem Programmierprinzip, die Schnittstellen möglichst klein zu halten (small interfaces). Allerdings kann man dieses Problem abmildern, wenn man für jeden Kommunikationskanal eigene, möglichst schlanke Kommunikationsschnittstellen definiert.

Details siehe: MVC-Pattern: Initialisierung mittels Dependency Injection

6.3 Kommunikation ausschließlich mittels des Observer-Patterns

Bei diesem Pattern kommunizeren alle MVC-Objekte mittels Multicast-Nachrichten (die alle notwendigen Informationen beeinhalten, so dass der Empfänger nie beim Sender rückfragen muss).

Die Zuweisung der Nachrichten-Sender zu ihren Nachrichten-Empfängern erfolgt während der Initialisierungsphase von außerhalb. Das heißt, die einzelnen MVC-Objekte kennen einander nicht.

Der Nachteil dieses Patterns ist, dass die eine Multicast-Kommunikation weniger effizient ist, als eine Unicast-Kommunikation. In zeitkritischen Anwendungen kann dies evtl. zu Problemen führen.

Details siehe: MVC-Pattern: Kommunikation ausschließlich mittels des Observer Patterns

7 Quellen

  1. Gamma et al. (1995): Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides; Design Patterns – Elements of Reusable Object-Oriented Software; Auflage: 1; Verlag: Addison-Wesley Longman; Adresse: Amsterdam; ISBN: 0201633612; 1995; Quellengüte: 5 (Buch)
  2. Kowarschick (MMProg): Wolfgang Kowarschick; Vorlesung „Multimedia-Programmierung“; Hochschule: Hochschule Augsburg; Adresse: Augsburg; Web-Link; 2018; Quellengüte: 3 (Vorlesung)

8 Siehe auch