Model-View-Controller

Model-View-Controller-Architektur wurde erstmals in Smalltalk-80 zur Konstruktion von grafischer Benutzerschnittstellen eingeführt. Es ermöglicht mehrere Ansichten für dieselben Daten bereitzustellen.Heutzutage ist MVC-Paradigma speziell bei interaktiven Systemen einsetzbar.
Interaktive Systeme
Bei interaktiven Systemen steht die Mensch-Maschine-Kommunikation und damit die Benutzerschnittstelle im Vordergrund. Der funktionale Kern und die Präsentation bzw. Benutzerschnittstelle sind bei interaktiven Systemen getrennt.Bei interaktive Systemen ist der funktionale Kern stabil, aber die Benutzerschnittstellen sind häufig durch Erweiterung der Funktionalität,Änderungen der graphischen Oberfläche,Portierung auf Plattformen mit anderem Look&Feel und Anforderungen des Benutzers von Änderungen betroffen.Starke Verbindung von Oberfläche und Funktionskern erschwert die Weiterentwicklung, da viele Stellen im System betroffen sind.Deswegen muss Präsentation und Berechnung getrennt sein.Dadurch kann dieselbe oder ähnliche Information auf unterschiedliche Art und Weise dargestellt werden.Dem Benutzer muss in interaktiven Systemen zur Verfügung gestellt werden, Informationen zu verändern und dem System neu hinzuzufügen.Die Benutzerschnittstelle soll zur Laufzeit durch Hinzufügen oder Ersetzung von Präsentationsformen gestaltbar sein.Um diese Kriterien erfüllen zu können,ist das interaktive System in drei Typen von Komponenten zerlegt:Model,View und Controller.
Das Fachkonzept ist Model. Die zentrale Berechnungskomponente, Model ist unabhängig von einer bestimmten Darstellung der Ausgabe oder einem bestimmten Verhalten der Eingabe.Es definiert die Funktionalität der Anwendung, und beinhaltet und kapselt deren Zustand. Es beantwortet zudem Fragen zum Zustand und informiert die Views über Änderungen.Model stellt noch die Methoden zur Berechnung und Verarbeitung von Eingaben zur Verfügung und ermöglicht Zugriff auf jene Daten, die dem Benutzer dargestellt werden.Die abhängige Sichten und Kontrollen werden bei dem Modell registriert und bei Datenänderung werden sie dem Komponenten benachrichtigt. View ist die Ausgabekomponente von dem MVC-Architektur. Die Views dienen zur Darstellung des Models,welches sie nach Änderungen befragen können.Die Eingaben vom Benutzer werden entgegengenommen und werden von dem View zum Controller gesendet.Die Views präsentieren dem Benutzer Informationen.View aktualisiert sich bei Veränderung der wesentlichen Informationen, nachdem es von dem Modell benachrichtigt wird.Die Views kommunuzieren mit dem Modell,um auf die geänderte Werte zuzugreifen.Eine passende Controller-Komponente wird von dem View erzeugt. Controller ist die Eingabekomponente, der das Verhalten der Anwendung definiert.Die Funktionalität des Modells,die auszuführen ist wird beim Controller definiert.Hierzu bildet er Benutzeraktionen auf Modelländerungen ab und wählt den für die Darstellung des Modells notwendigen View aus.Controller sind jeweils einer View-Komponente zugeordnet.Die beim Views aufgenommene Benutzereingaben werden hier entsprechend behandelt und dann werden die Aufträge an das Model weitergegeben.Controller veranlassen Views, sich nach Veränderungen zu aktualisieren.MVC ist ein sehr leistungsfähiges Design,weil mehrere Ansichten und Controller für ein einziges Modell dargestellt werden können.Ansichten werden automatisch benachrichtigt,wenn das Modell geändert wird.Dadurch hat der Benutzer immer das aktuelle View zur Verfügung. Bei MVC-Architektur werden die Komponente getrennt dargestellt,deswegen müssen Modelle nicht verändert werden,wenn neue Ansichten oder Controller hinzugefügt werden. Model-View-Controller Architekturmuster ist für Interaktive Anwendungen sehr geeignet, bei denen die Benutzerschnittstelle flexibel gehalten werden muss.



Änderungen des Model-Inhaltes sollen allen Komponenten mitgeteilt werden, die darauf hingewiesen sind, wie zum Beispiel die Views. Mit dem Änderungs-Verbreitungs Mechanismus kann die gesamte MVC-Architektur verfeinert werden.Verleger bietet Operationen zur An- und Abmeldung von Abonnente, die an Mitteilunges des Verlegers interessiert ist, sich durch Anmeldung beim Verleger registrieren.Bei neuer Mitteilung des Verlegers werden alle Abonnenten durch Aufruf einer bestimmten Methode benachrichtigt.Methode wird durch Schnittstelle definiert, die jeder Abonnent implementiert.Das nennt man Verleger-Abonnent Architektur.
Die lose Koppelung der drei Bestandteile bei MVC-Architekturmuster ermöglicht es, diese getrennt zu entwickeln und zu verwenden.So können mehrere Views erstellt werden, die verschiedene Bestandteile des Modells darstellen, ohne dieses hierfür ändern zu müssen.Muss das Modell angepasst werden, weil z.B. Daten anders verarbeitet werden sollen, ist andererseits keine Änderung an den Views notwendig. Auch innerhalb des Controllers können Änderungen vorgenommen werden, z.B. bei der Auswahl der anzuzeigenden Views, ohne dass diese Auswirkungen auf die anderen Bestandteile haben.
Ein dynamisches Beispiel könnte folgendermaßen aussehen:Nachdem der Controller eine Eingabe(handleEvent)erhält, ändert es das Modell(service).Das Modell benachrichtigt(update) die registrierten Beobachter, die daraufhin vom Modell den aktuellen Zustand erfragt(getData)haben.Die Beobachter bringen sich dann selbst auf den neuesten Stand(display).

MVC wird in Java implementiert, indem die Schnittstellen für View, Controller und Abonnenten definiert werden.GUI-Komponenten werden in AWT oder Swing spezialisiert.(View) Views erzeugen bei Benutzereingaben Standard-Ereignisse,wie z.B.ActionEvent, TextEvent,usw. Dann werden die entsprechende EventListener implementiert(Controller).Und bei dem Model werden die Änderungs-Verbreitungs-Mechanismus und Funktionalität der interaktiven Anwendung implementiert.
MVC-Architektur für Swing: Das MVC-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. Wenn man zum Beispiel eine Textkomponente implementieren möchte, müsste man 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 Modell ergeben, führt die Benachrichtigung immer über den Controller.
Es macht demnach Sinn, VC zu einer Komponente zu verschmelzen, um die komplexe Interaktion zwischen View und Controller zu vereinfachen. In Swing findet sich keine Reinform des MVC, sondern eine Verquickung von View und Controller. Durch diese Vereinfachung lassen sich die Benutzeroberflächen leichter programmieren,wobei man wenig Flexibilität einbüßt.Das neue Modell wird anstatt MVC auch Model-View-Presenter (MVP-Pattern) genannt.Die Daten in einem Arbeitsblatt entsprechen den Daten, die unterschiedlich visualisiert werden können: klassisch in einem Tabellenblatt und modisch in einem Diagramm. Ein Modell 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. In Java sind der View und der Controller durch ein Objekt ComponentUI repräsentiert. Da man das Aussehen und Verhalten von Java-Komponenten frei bestimmen kann, gibt es demnach für alle konkreten Swing-Komponenten ein ComponentUI-Objekt, welches die Darstellung und Benutzeraktionen übernimmt. Ein JList-Objekt verweist dann auf eine paint()-Methode im ComponentUI-Objekt, das die Darstellung wirklich vornehmen kann.
Variante
Es gibt verschiedene Varianten von Model-View-Controller Architekturmuster. Document-View-Architektur ist eine Variante von MVC-Architektur. Die benutzer-interaktive Komponenten in Ausgabe-und Eingabe-Komponenten werden nicht aufgespaltet. View übernimmt sowohl Darstellung von Informationen als auch Verarbeitung von benutzer-erzeugten Ereignissen. Document-Komponente entspricht dem Model in MVC. Die Implementierung der Architektur besteht aus folgende Schritte:Die Kernfunktionalität wird zuerst von der Mensch-Maschine-Interaktion getrennt.Die Kernfunktionalität wird im Modell realisiert. In der Oberfläche werden lediglich die Funktionen angestoßen und die Ergebnisse dargestellt.Es ist ein Vollständiges Design ohne GUI. Danach wird geklärt welche Funktionalität dem Benutzer über Controllsangeboten wird und wie die Schnittstellenkomponenten im Modell aussehen.Die Kommunikation zwischen Model und die Komponente wird mit dem Änderungs-Verbreitungs-Mechanismus implementiert wird.Die Views und zugehörige Controller werden entworfen und implementiert.Dies beinhaltet neben der Display-Funktion, die die Inhalte anfordern die Implementierung der Update-Funktion. In der einfachsten Variante besteht dies direkt im Aufruf der Display-Funktion.Die zusätzliche Parameter ermöglichen Optimierungen,wie die Verzögerung der Aktualisierung, da noch weitere Updates kommen.Eine Initialisierungsroutine meldet dann die View an und erzeugt den Controller.Für jede View werden die Bedienmöglichkeiten festgelegt, die der Anwender ausführen kann. Ein Controller erhält und interpretiertdie Eingaben und bildet sie auf entsprechende System-Funktionen up (service()). Die Initialisierung des Controllers verbindet ihn mit Modell und View.DAnn wird die Kommunikation zwischen View und Controller hergestellt.Jede Viewerzeugt ihren Controller. Für eine Hierarchie von Views ist es angebracht die Erzeugung der Controller z. B. über Fabrikmethoden zu organisieren.Am Ende muss das gesamte MVC-System initialisiert werden.Zu erst wird das Modell erzeugt,danach die Views.Diese attachen sich am Modell und erzeugen ihre Controlls.Wenn diese Initialisierung abgeschlossen ist,wird die Haupt-Schleife gestartet.
Zum Schluß kann das Model-View-Controller-Muster so klassifiziert werden.MVC ist ein Software Architekturmuster,das speziell bei interaktiven Systemen einsetzbar ist.z.B.GUI-Bibliotheken, Smalltalk, Microsoft Foundation Classes. Die Hauptkonzepte bei VC-Arcihtektur sind Dekomposition und Interaktionsregelung .MVC hat eine mittlere Komplexität und ist varientenarm.Aber es wird mehrere synchrone Sichten von desselben Modell dargestellt,was bei interaktiven Systemen sehr wichtig ist.Die Modelle und Kontrollen sind stark gekoppelt.

http://java.sun.com/blueprints/patterns/MVC-detailed.html
Application Programming in Smalltalk-How to use Model-View-Controller (MVC),Steve Burbeck
http://www.informatik.fh-muenchen.de/~schieder/seminar-oo-modellieren-ws97-98/f7alpha1.informatik.fh-muenchen.de/~ifw94032/index.html
http://atbruegge27.informatik.tu-muenchen.de/teaching/ss02/muster/index.html
http://developer.apple.com/documentation/Cocoa/Conceptual/AppArchitecture/Concepts/MVC.html