Thema: Das Model-View-Controller Modell
                (MVC-Modell)

Autor: Simon Acker
Erstellungsdatum: 16.12.04

 

Definitionen

Definition (nach Mark Guzdial in seinem Buch "Squeak") Das MVC-Modell beschreibt im Grunde genommen eine Benutzerschnittstelle in Form von einem "Model" der realen Welt, welches durch eine "View" präsentiert wird, wobei Benutzereingaben durch ein oder mehrere "Controller" gehandhabt werden.

Definition (nach Simon Lewis in seinem Buch "The Art and Science of Smalltalk")
Das MVC-Modell ist ein grundlegender Architekturbaustein von Smalltalk, in welchem die Funktionalität einer Applikation mit einer graphischen Benutzerschnittstelle (GUI) in die drei Bereiche "Model", "View" und "Controller" gegliedert wird.

 

 

Beschreibung des MVC-Modells

Die Idee des MVC-Modells entsprang aus der Erstellung von Benutzeroberflächen mit Smalltalk-80. Ziel war eine Trennung interaktiver Applikationen in Subsysteme mit eigener, in sich geschlossener Funktionalität. Dabei war dieser Gedanke kein neuer Stern am Himmel der Softwareentwicklung, sondern vielmehr der Wunsch, die bisher bestehende Trennung von Eingabe, Verarbeitung und Ausgabe auf GUI-basierte Systeme zu übertragen.
Betrachten wir uns nun die Struktur des MVC-Modells genauer, so lässt sich folgende Begriffszuordnung festlegen: Das Model entspricht der Verarbeitung, die View der Ausgabe, sowie der Controller der Eingabe.
Das MVC-Modell ist ein Entwurfsmuster zur Trennung bestimmter Programmeigenschaften eines interaktiven Systems in drei Einheiten: Datenmodell (Model), Präsentation (View) und Programmsteuerung (Controller). Dabei enthält das Model die Kernfunktionalität und die Daten der Anwendung, die View stellt Informationen für den Benutzer graphisch dar und der Controller verarbeitet die Benutzereingaben. View und Controller bilden zusammen die Benutzerschnittstelle (UI) des Systems. Die Kommunikation zwischen UI und dem Model läuft über eine Benachrichtigungsstrategie ab.
Jede dieser drei Komponenten sollte als eigener Baustein implementiert werden. Grund dieser Unterteilung ist zum einen, dass eine feste Verwebung des UI (View, Controller) mit dem Funktionalen Kern (Model) ein Ausmaß an Komplexität bei Änderung einer dieser Komponenten bedeuten würde. Zum anderen könnten leicht mehrere Views auf ein und dasselbe Model zugreifen um so verschiedene Darstellungen zu ermöglichen. Weiterhin erlaubt die Trennung der Benutzerschnittstelle in Controller- und Viewkomponente, dass einer View mehrere Arten von Controllern zur Verfügung gestellt werden könnten. (Man denke an ein CAD-Programm in welchem dieselbe View je nach Anwendung (Tutorial Sitzung, Normale Sitzung, Experten Sitzung, etc.) verschiedene Controller bereitstellt.) Es ergibt sich bei der Trennung in eigenständige Komponenten eine flexibleres Programmdesign in Hinblick auf Änderung, Erweiterung und Wiederverwendbarkeit der einzelnen Komponenten. Die Trennung verschafft Übersicht und Ordnung vor allem in großen Anwendungen und ermöglicht eine bessere Rollenverteilung der Spezialisten (z.B. Web Designer für View, Programmierer für Controller, Datenbankspezialist für Model).
Über die implementierte Benachrichtigungsstrategie stellt das MVC-Modell sicher, dass bei jeder Änderung des Model auch alle dazugehörigen Views und Controller aktualisiert werden. Darauf gehen wir nun in der Detailbetrachtung der einzelnen Komponenten genauer ein:
(Übrigens handelt es sich streng genommen bei dem MVC-Modell nicht um ein Entwurfsmuster, denn es ist kein allgemeines, beliebig verwendbares Muster. Es stellt vielmehr einen ganz konkreten Anwendungsfall dar - die graphische Oberfläche!)

 

 

Komponenten des MVC-Modells

Model
Das Model ist verantwortlich für die Durchführung von Berechnungen. Es kapselt die Kern-Daten und -Funktionalität einer Applikation. (Als Bestandteil der Kern-Funktionalität stehen Methoden zur Manipulation der Daten zur Verfügung, welche durch einen Controller aufgerufen werden können. Weiterhin gibt es Methoden zur Lieferung von Daten welche die Views aufrufen können.) Das Model kennt keine konkreten Views und Controller, weiß also nicht wie, ob und wie oft es selber dargestellt werden wird. Views haben aber die Möglichkeit sich beim Model zu registrieren um bei Veränderung des Datenbestands benachrichtigt zu werden und entsprechend darauf zu reagieren. (Das ganze geschieht, indem das Model Zeiger auf die Viewbasisklasse besitzt, sog. weak-typed Pointer, und so die Basisschnittstelle aller Views benutzen kann.) Bei einer Veränderung wird ein Event ausgelöst, welcher die Benachrichtigung der registrierten Views nach sich zieht. Das Model kann wie bereits angedeutet mit beliebig vielen Views verbunden sein und hat Zugriff auf diverse Backend-Speicher(z.B. Datenbanken).

View
Die View ist verantwortlich für die Präsentation. Sie zeigt dem Anwender Informationen über das Model an, bereitet also die Daten des Model (oder Teile davon) in graphischer Darstellung auf. Eine View kennt immer genau ein Model. Falls sich Daten des Model ändern, so wird die View darüber vom Model benachrichtigt. Die View führt eine update-Methode aus, in der sie sich den aktuellen Datenzustand des Model holt(Methodenaufruf im Model) und ihre Darstellung sofort dementsprechend aktualisiert. (Dies ist möglich, da jede View einen Pointer auf ein konkretes Model besitzt, sog. strong-typed Pointer, und infolge dessen direkte Methodenaufrufe durchführen kann.) Weiter hält die View einen Pointer auf den Controller, der wegen Austauschbarkeitsgründen nur ein weak-typed Pointer ist. Die View kann also gegebenenfalls zugeordnete Controller erzeugen.

Controller
Der Controller ist verantwortlich für die Interaktion. Er definiert die Benutzerinteraktion der Applikation - er definiert die Reaktion der Benutzerschnittstelle auf die Eingabe. So nimmt er Benutzereingaben entgegen und bildet diese dann mit Hilfe der anderen Schichten auf Dienstanforderungen (Anzeigedienste der View oder datenverarbeitende Dienste des Model) ab. Um die entsprechenden Methoden bei View bzw. Controller aufzurufen, muss der Controller natürlich beide als konkrete Klassen kennen, sie also per strong-typed Pointer halten. Der Controller erhält Benutzereingaben normalerweise über Ereignisse die Daten bezüglich Mausbewegungen, Mausereignisse oder Tastertureingaben enthalten. Solche Eingaben wandelt der Controller dann in Anfragen an die View oder das Model um. Abschließend ist noch zu bemerken, dass der Benutzer ausschließlich über den Controller mit dem System interagiert.

 

 

Abschließende Bemerkungen

Die Kommunikation zwischen Model und View regelt ein sogenanntes subscribe/notify-Protokoll. Wie bereits beschrieben melden sich Views beim Model an und werden bei dessen Änderung darüber benachrichtigt. Verallgemeinert beschreibt diesen Sachverhalt das sog. Observer-Design Pattern, welches bei der Implementierung eines Systems durch MVC eine wichtige Rolle spielt.

Eine MVC-Komponente wie die View kann selbst wieder aus wiederverwendbaren Views und Controllern bestehen. Dies sind im allgemeinen häufig gebrauchte Elemente wie Buttons, Menüs, etc. Es ist also für die Erstellung der Benutzerschnittstelle durchaus eine hierarchische Gliederung sinnvoll.

 

 

Abschließendes Beispiel


Hier ist nochmal der funktionale Zusammenhang der MVC-Komponenten skizziert.

 

 

 

Als Beispiel betrachten wir einen Spinner:
Über die Buttons (Up,Down) lassen sich ActionEvents erzeugen (Benutzereingabe).
Der implementierte ActionListener (Controller) fängt das Ereignis auf und
ermöglicht nun eine Inkrementierung/Dekrementierung der darzustellenden
Daten des Spinners (Model). Geschah dies wird das TextField des Spinners (View)
über die aktualisierten Daten benachrichtigt, woraufhin sie sich die Daten
holt(update- Methode) und die graphische Oberfläche erneuert.

 

 

Verwendete Quellen:
http://www.computerbase.de/lexikon/Model_View_Controller
http://www.fh-wedel.de/~si/seminare/ws97/Ausarbeitung/3.Krutscher/archmu3.htm
http://fara.cs.uni-potsdam.de/~kaufmann/tuts/mvc.pdf
http://beat.doebe.li/bibliothek/w01609.html
http://ootips.org/mvc-pattern.html
http://www.vico.org/pages/PatronsDisseny/Pattern%20Model%20View%20Controller/
http://en.wikipedia.org/wiki/Model-view-controller
http://ifgi.uni-muenster.de/~bernard/public/GeosI/Sitzung6.ppt
http://www.inf.fu-berlin.de/lehre/SS03/aws/mvc.pdf
http://www.st.cs.uni-sb.de/edu/sopra/2004/arch.pdf
http://www.enode.com/x/markup/tutorial/mvc.html

 

Bei Fragen oder Anregungen schreibt mir bitte eine EMAIL.