MVC - Model View Controller

Jede interaktive Anwendung besteht aus Eingaben, einem Datenmodell und der Darstellung der Daten auf dem Bildschirm.
So lassen sich z. B. dieselben Daten entweder alpha-numerisch oder grafisch darstellen.

CDU	42,4
FDP	3,2
Grüne	11,7
PDS	4,9
SPD	26,1

Daten, Eingaben und ihre Darstellung als Einheit

Eine - problematische - Möglichkeit der Realisation besteht darin, diese drei Ebenen jeweils nach Bedarf in einer Klasse zusammenzufassen:

procedure TArtikel.Anzeigen;
// ------------------------------------
begin
NummerEdt.Text := inttostr(Nummer);
BezEdt.Text := Bezeichnung;
PreisEdt.Text := floattostr(Preis);
end;

Software Design – integrative Lösung. Daten, Eingaben und Ausgaben sind in einer Klasse vereint.

Das Model-View-Controller Konzept

Eine andere Möglichkeit (MVC) trennt die Ebenen in drei selbständige Einheiten. Der Begriff Model wird für die Applikation ohne Benutzungsoberflächen (Fachkonzept), also für die interne Datenverarbeitung verwendet. Die einzelnen Views sind für die aktuelle Darstellung der Eingangs- und Ausgangsdaten in den jeweiligen Anzeigeobjekten (Editfelder, Menüs, Dialogboxen usw.) verantwortlich. Sie werden dabei von der Windowsverwaltung unterstützt.

Der Controller überwacht alle Eingabegeräte. Eingabedaten werden an das zuständige Fenster weitergeleitet. Änderungen der Modelldaten werden also vom Controller eingeleitet. View und Controller bilden zusammen die Benutzungsoberfläche.

Diese Beziehungen bestimmen den möglichen Fluss der Botschaften und der Daten. Das besondere Kennzeichen der Architektur ist die Tatsache, dass das Model weder die Views noch den Controller kennt. (Praktisch heißt das, dass in den Datenklassen keine View– oder Controllerelemente aufgerufen werden dürfen!) Dies bedeutet, dass die interne Datenverarbeitung von der Benutzungsoberfläche gänzlich abgekoppelt ist. Änderungen in der Benutzungsoberfläche haben also keine Auswirkung auf die interne Verarbeitung der Daten und der Datenstruktur. Damit wird jedoch auch die Möglichkeit eröffnet, gleichzeitig die Daten mehrfach unterschiedlich darstellen zu können, z. B. die numerischen Prozentzahlen eines Wahlergebnisses als Tabelle, als Balken- oder Tortendiagramm.

Die Controllerelemente werden bei grafischen Oberflächen mit Hilfe der Ereignissteuerung aktiviert. Der Ablauf des Programms folgt damit keinem starren Schema wie bei dem EVA-Prinzip, sondern wird durch frei wählbare beliebige Aktionen des Benutzers gesteuert.

GUI - Fachklasse

Daten, Repräsentation und Eingaben sind getrennt.

mvc_0.3.gif (1971 Byte)

Zu dem reinen Datenobjekt (MODEL) kommen selbständige GUI-Objekte (WINDOW, TEXTBOX, BUTTON ) hinzu.

VIEW und CONTROL werden häufig in einem Fensterobjekt zusammengefasst.

Zu jedem MODEL gehört ein VIEW–CONTROLLER-Paar.

MODEL weiß nichts über VIEW-CONTROLLER.

VIEW-CONTROLLER kennen MODEL, holen von und schicken ihm die Daten.

Zwischen den GUI-Objekten und dem MODEL-Objekt muss eine Verbindung hergestellt werden.

Die Model-Klassen müssen entwickelt und entsprechend dem MVC-Mechanismus zu den View-Klassen in Beziehung gesetzt werden. Das kann z. B. in Delphi mit zwei Methoden erledigt werden:

procedure TFensterFrm.DatenAktualisieren(var Art : TArtikel);
// ----------------------------------------------------------
begin
Art.SetNummer (StrToInt(NummerEdt.Text));         // VIEW ==> Model
Art.SetBezeichnung (BezeichnungEdt.Text);
Art.SetPreis (StrToFloat (PreisEdt.Text));
end;

procedure TFensterFrm.MaskeAktualisieren(Art : TArtikel);
// ----------------------------------------------------------
begin
NummerEdt.Text      := IntToStr(Art.GetNummer);   // VIEW <== Model
BezeichnungEdt.Text := (Art.GetBezeichnung);
PreisEdt.Text       := FloatToStr (Art.GetPreis);
end;

(Implementierungsbeispiele / Design Pattern finden sie unter MVC mit DELPHI)

Der große Vorteil dieser Architektur besteht darin, dass eine bruchlose Verbindung zwischen den objektorientierten GUI-Klassen und einem objektorientierten Model möglich ist. Allgemeiner betrachtet kann die Unterscheidung in Model und View mit den Kategorien Wesen und Erscheinung gleichgesetzt werden.

Hinzu kommt, dass schnell ein Prototyp der Applikation, bzw. der Benutzungsoberfläche erstellt werden kann, ohne dass das Model bereits fertig vorliegt. Unterstützt wird dies insbesondere dann, wenn die Entwicklungsumgebung das interaktive Erstellen von Oberflächen mit einem GUI-Builder ermöglicht.