Model-View-Controller:

Johannes Vetter 12/10/2004

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.

Aufgaben der einzelnen Schichten im Detail:

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.

Wie interagieren diese Schichten nun miteinander?

Wird im Model eine Veränderung registriert werden sofort alle angebundenen Views über eine Updatefunktion benachrichtigt das bedeutet, dass die Views dazu aufgefordert werden sich die aktualisierten Daten anzusehen und sie entsprechend ihrer Spezifizierung auf dem Bildschirm wiederzugeben. Um dies zu ermöglichen müssen sich die Views beim entsprechenden Model anmelden damit das Model einen Überblick darüber hat an welche Views jeweils ein Update herausgeschickt werden muss. Im allgemeinen geschieht die gesamte Kommunikation zwischen Model und View über ein Observer-Design-Pattern was hier nicht näher erläutert wird. Wichtig ist, dass bei einer Änderung des Models immer alle Views aktualisiert werden, da es ja sein kann das bestimmte Werte über unterschiedliche Views einstellbar sind, und diese müssen natürlich immer auf dem neusten stand gehalten werde damit es bei späteren Umstellungen an den evtl. nicht aktualisierten Views nicht zu einer fehlerhaften Interpretation kommt.

Wo liegen nun die Vor und Nachteile einer solchen Implementierung?

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.

Konkretes Beispiel:

Wie arbeitet MVC beim Aufbau von Java GUI's mittels Swing?

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.

Conclusion:

Verallgemeinert lässt sich sagen, dass das Model View Controller Konzept ein durchaus leistungsstarkes Instrument zur Implementierung von Benutzeroberflächen ist. Dennoch ist es nicht das Maß aller Dinge und ist trotz seiner vielfachen Anwendbarkeit mit Problemen behaftet. Deshalb muss man vor der Implementierung eines jeden Interfaces prüfen, ob das MVC dazu geeignet ist oder nicht. Die Kriterien zum treffen einer solchen Entscheidung kann man aus den Vor und Nachteilen der unterschiedlichen Konzepte ableiten.

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