Beim Model View Controller Konzept handelt es sich um eines der bekanntesten
Entwurfsmuster zur Trennung von verschiedenen Programmeigenschaften welches
ursprünglich aus der Erstellung von Benutzeroberflächen in SmallTalk
entstanden ist. Heutzutage wird es vor allem zur Programmierung interaktiver
Systeme verwendet.
Ziel dabei ist es die Änderungen am Programm zu einem späteren Zeitpunkt
möglichst einfach zu gestalten. Des weiteren soll die Widerverwendbarkeit
von Codefragmenten ermöglicht werden. Als Nebeneffekt erhält man durch
die Verwendung dieses Konzeptes eine übersichtliche Struktur des Programms.
Noch ein weiterer Vorteil dieses Konzeptes besteht darin, dass verschiedene
Mitarbeiter eines Projektes speziell nach Ihren Fähigkeiten eingesetzt
werden können. Der Designer kümmert sich um die View, der Programmierer
erstellt die Logik und der Datenbankexperte kümmert sich um die Datenhaltung.
In der Softwareentwicklung ist das Prinzip der Trennung von Eingabe, Verarbeitung
und Ausgabe schon lange bekannt. Mit dem Model View Controller Konzept wird
dies nun auf GUI-Basierte Systeme übertragen.
Das Model ist für die Verwaltung, Manipulation und Verarbeitung von Daten eines Systems zuständig. Es ist unabhängig von der Darstellungsweise der Daten und von dem Verhalten der Eingabe. Es verkapselt diese nur. Das Model kennt die entsprechende View nicht, kann jedoch über eine Methode Update signalisieren, dass sich an den Daten etwas geändert hat und die Views können sich dann auf den neusten Stand der Dinge bringen. Ein Model kann mit beliebig vielen Views verbunden sein und arbeitet somit mit der View und dem Controller zusammen.
Die View dient zur Abbildung der Daten und stellt somit eine mögliche Darstellung des Models dar. Eine View ist immer mit genau einem Model verbunden, was aber nicht impliziert, dass ein Model nur eine View haben kann, das würde dann der Grundidee von Model View Controller wiedersprechen. Für den Fall einer Änderung der Daten stellt die View diese sofort entsprechend dar. Des weiteren besitzt die View einen Schnittstelle zum Controller Objekt, das heißt die View arbeitet mit dem Controller und dem Model zusammen.
Der Controller ist für die Interaktion mit dem Benutzer zuständig. Er ist sowohl mit der View als auch mit dem Model verbunden um entsprechende Funktionalitäten ausführen zu können. Er verarbeitet Eingaben und ruft entsprechende Dienste der zugeordneten Sicht oder des Models auf. Jeder Kontrolle ist eine Sicht zugeordnet. Es kann jedoch mehrere Controller in einem Model geben.
Vorteile findet man zum einen in der Möglichkeit, dass ein und dasselbe
Datenmodell in mehreren Ansichten repräsentiert werden kann. Des weiteren
sind alle Ansichten die sich auf ein Modell Beziehen automatisch synchronisiert
und es können Bedienelemente beliebig vertauscht werden. Außerdem
ist es ohne weiteres möglich auf eine vorhandenes Model eine neue View
zu implementieren. Dadurch ist ein solches System nahezu beliebig skalierbar.
Ein Nachteil besteht darin, dass der zugriff mehrerer Views auf ein Model schnell
zu einer hohen Komplexität führen kann und sich dadurch fehlerhafte
Stellen im Programm schwerer ausfindig machen lassen. Des weitern kann man teilweise
von einem ineffizienten Datenzugriff innerhalb einer Ansicht sprechen, da immer
noch ein Objekt dazwischen geschaltet ist. Außerdem ist dass MVC-Konzept
schwierig in WYSIWYG-Werkzeuge zu integrieren. Auch die starke Koppelung zwischen
Modell und Sicht sowie zwischen Modell und Controller kann als Nachteil interpretiert
werden.
In Java wird auch eine Kommunikation über ein Observer Pattern hergestellt.
Es gibt einen Beobachter der in diesem Fall unsere View darstellt und einen
zu beobachtenden welcher im oben genannten Konzept das Modell ist.
Das Model View Controller Konzept trennt ganz klar die Bereiche ab, führt
aber bei praktischer Realisierung zu zwei Problemen. Das erste betrifft die
Entwickler der Komponenten. Meistens sind View und Controller eng verbunden,
so dass es zusätzlichen Schnittstellenaufwand für die Implementierung
gibt. Implementieren wir etwa eine Textkomponente, müsste sie sich um alle
Eingaben kümmern und diese dann an die Darstellung weiterleiten. Das zweite
sich daraus ergebende Problem ist der erhöhte Kommunikationsaufwand zwischen
den Objekten. Wenn sich Ergebnisse in der Darstellung oder dem Model ergeben,
führt die Benachrichtigung immer über den Controller.
Es macht demnach Sinn, View und Controller zu einer Komponente zu verschmelzen,
um die komplexe Interaktion zwischen View und Controller zu vereinfachen. Genauso
haben es die Entwickler der JFC daher gemacht. In Swing findet sich keine Reinform
des Model View Controller, sondern eine Verquickung von View und Controller.
Durch diese Vereinfachung lassen sich die Benutzeroberflächen leichter
programmieren, wobei wir nur wenig Flexibilität einbüßen. Das
neue Model wird anstatt Model View Controller auch Model View Presenter (MVP-Pattern)
genannt. Betrachten wir das MVP-Konzept am Beispiel einer Tabellenkalkulation.
Die Daten in einem Arbeitsblatt entsprechen den Daten, die unterschiedlich visualisiert
werden können: klassisch in einem Tabellenblatt und modisch in einem Diagramm.
Ein Model kann problemlos mehrere Sichten haben. Eine Änderung der Daten
im Tabellenblatt führt nun zu einer Änderung in den internen Daten,
und umgekehrt führen diese zu einer Änderung des Diagramms.
http://de.wikipedia.org/wiki/MVC
fara.cs.uni-potsdam.de/~kaufmann/tuts/mvc.pdf
www.inf.fu-berlin.de/lehre/SS03/aws/mvc.pdf
beat.doebe.li/bibliothek/w01609.html