Erklärung |
Das Model-View-Controller Entwurfsmuster entkoppelt Darstellung, Benutzerinteraktion und Datenmodell. Dabei bilden Controller und View eine grafische Benutzerschnittstelle für das Modell.
Im Kontext einer Desktopanwendung liefert der View eine Darstellung des im Modell vorgehaltenen Zustands. Der Controller ist für die Verarbeitung der Maus- und Tastaturereignisse verantwortlich. Er bedient sich ggf. des Views, um zu ermitteln, in welchem Teil der Darstellung das Ereignis stattgefunden hat und kann daraufhin im Modell eine Reaktion auf das Ereignis anstoßen. Er reicht außerdem die nur den View betreffenden Ereignisse an diesen weiter. Das Neuzeichnen von Teilen eines Fensters läuft z. B. üblicherweise über Betriebssystem-Events.
Beim Modell können sich Beobachter registrieren. Das Modell meldet Zustandsänderungen an die Liste seiner Beobachter (BeobachterMuster). Im MVC ist typischerweise mindestens der View ein Beobachter des Modells.
Die Stärke der Entkopplung von View, Controller und Modell wird deutlich, wenn ein Modell mehrere Benutzerschnittstellen bekommen soll. Durch Austausch des Controllers lassen sich z. B. Kontextmenüs verändern, Editieraktionen unterbinden, Maustasten austauschen und dergleichen mehr. Austausch des Views kann bedeuten, zwischen einer rein textuellen und einer grafischen Repräsentation oder zwischen einem Balken- und einem Tortendiagramm umzuschalten. Für ein anderes Look & Feel tauscht man sowohl View als auch Controller aus. Oft stellen Anwendungen auch verschiedene Eingabemöglichkeiten für ein Modell bereit, etwa einen Farbwähler nach dem RGB-Modll und einen nach dem CMYK-Modell.
In vielen GUI-Bibliotheken kommunizieren die einzelnen Widgets ziemlich ungeordnet miteinander. Jedes hat einen internen Zustand, den es laufend mit anderen Widgets und dem Rest der Anwendung synchronisieren muss. In MVC wird diese zyklische Abhängigkeit aufgebrochen (ein Bespiel für das DependencyInversionPrinciple?). Jeder View beobachtet nur ein Modell, aber es kann viele Views für dasselbe Modell geben. Controller steuern Modelle fern. Es gibt normalerweise viele Controller, die dasselbe Model steuern, manchmal steuert auch ein Controller mehr als ein Modell und oft liegen Adapter dazwischen. Jedoch hat nur das Modell einen bedeutsamen internen Zustand, und ganz im Sinne von OnceAndOnlyOnce muss der mit keinem anderen Zustand synchronisiert werden.
Die Trennlinie zwischen Model, View und Controler ist nicht immer eindeutig. Wichtig ist jedoch, dass das Modell über das BeobachterMuster von den GUI-Komponenten entkoppelt wird, denn erst damit wird ein Austausch der GUI ohne Änderung des Modells möglich.
Geschichte |
Der Begriff MVC entstand 1978/79 bei XeroxParc. Ursprünglich war die Betrachtung nicht auf Model, View und Controller beschränkt. Zusätzlich gab es die Konzepte Thing und Editor:
Ein wichtiger Bestandteil der Implementation für Smalltalk-80 bestand in der Entkopplung der Präsentationsschicht vom Modell über das BeobachterMuster: In VisualWorksSmalltalk wurde das Konzept erweitert um ein ApplicationModel. Dies repräsentiert eine in sich abgeschlossene grafische Oberfläche für ein Geschäftsmodell. In der Regel gibt es pro Dialog ein solches ApplicationModel, es lassen sich aber auch mehrere dieser Anwendungs-Modelle ineinander schachteln.In DolphinSmalltalk wurde als Gegenentwurf das ModelViewPresenterPattern perfektioniert.
Verwässert wurde der Begriff MVC unter anderem durch die Verwendung im Zusammenhang mit Entwurfsmustern zur Webentwicklung mit Java. Im Zusammenhang mit den JavaServerPages wurden die Begriffe Model 1 und Model 2 geprägt. In Beschreibungen von Model 2 findet sich stets der Hinweis, damit werde MVC umgesetzt. Üblicherweise spielen dann JavaServlets die Rolle von Controllern, während eine JSP-Seite die Rolle des Views übernimmt. JavaBeans? bilden das Model.
Information |
Hier einige Beschreibungen von MVC:
Beispiele für MVC |
MVC oder nicht? |
Obwohl MVC in der Literatur häufig erwähnt wird, findet man reinrassiges MVC eher selten. Das liegt vor allem daran, dass man in vielen Anwendungsfällen nur schwer eine eindeutige Trennung von View und Controller vornehmen kann. Zum Beispiel hat das Java-Framework Swing zwar Wurzeln im MVC, legt aber View und Controller zusammen:
Das JFace Data-Binding ist entgegen mancher Darstellungen auch kein MVC sondern eher eine Erweiterung des Mediator-Patterns:Das Schlüsselwort bind in SpracheJavaFX ist eine Art in die Sprache integrierter AspectAdaptor. Mal abgesehen davon, dass das Schlüsselwort durchaus auch einige Nachteile mit sich bringt: View updates über Modelländerungen kann man damit sehr einfach umsetzen. Viel einfacher, als z. B. in Java Swing. Weiterführende Links:
Eine andere Quelle für Verwechslungen ist das Muster Entity-Control-Boundary: Selbst in SpracheSmalltalk findet eine Abkehr vom ursprünglichen MVC statt: