MVC - Was darf View

[Elephant]

Hallo,

meine Frage bezieht sich auf das MVC - Pattern. Ich hab schon im Internet gesucht, dort gibt es nur so viele Antworten, die alle was anderes sagen, dass ich nicht mehr so ganz durchblicke. Ich hab diese Frage auch schon woanders gestellt, aber währenddessen sind mir noch weitere Fragen eingefallen, deshalb stellt ich sie noch einmal hier.

Also die View 'beobachtet' ja das Model und wird bei Änderungen benachrichtigt. Darf nun die Klasse, die als View 'benutzt' wird (also eine GUI-Klasse, die die Swing-Oberfläche erstellt) über getter-Methoden auf die Daten des Models direkt zugreifen und sich die geänderten Daten holen oder muss dies über den Controller geschehen oder ganz anders?

Und wie ist es wenn ich z.B. eine Klasse habe, die für das GUI zuständig ist und der User dort zwischen mehreren Optionen mittels JRadioButtons etwas auswählen und z.B. einen Text in ein JTextField eingeben kann etc. Sollte zu einer 'GUI-Klasse' immer eine Klasse existieren, die als Model 'arbeitet' und in der es für z.B. jeden JRadioButton eine Variable gibt und für das JTextField, so dass man dann z.B. die Belegung der JRadioButtons vom Model abfragt und dort auch wieder speichert, wenn sich etwas ändert.

Also konkret, ich habe ein JTextField. Ich kann etwas hineinschreiben oder es wird z.B. beim Aufruf eines JFileChoosers gesetzt, je nachdem was in dem Feld steht muss die GUI angepasst werden. Schreibe ich die Daten des Feldes bei einer Änderung immer in eine Variable in eine Klasse, die als Model fungiert und berechne dort die Änderungen, die dann wieder vom View abgefragt werden, oder übergebe ich den Inhalt des Feldes erst, wenn ich z.B. auf den Button 'Finish' klicke und 'berechne' die Änderungen erstmal alle in der 'GUI-Klasse'?

 

[bygones]

cih weiß nicht ob du die Ebene Model richtig verstanden hast, die letzten Beispiele verwirren mich da.

Das Model hält die reinen Modeldaten. Wie und was in der View angezeigt wird ist Sache der View. D.h. ob jetzt Button 1 oder 2 gedrückt wurde und danach ein FileChooser oder so aufgerufen wird hat eigentlich nichts mit dem Model zu tun.

Ansonsten, sobald du vom Model etwas ändern willst, so soll das über den Controller laufen...

 

[Elephant]

Also ich meine, wenn ich ein Feld habe, in das der Pfad zu einer Datei eingetragen werden soll, dann gebe ich den Pfad ja später an eine Klasse weiter, die mit dem Pfad arbeitet. Das heißt der Pfad ist ein Datum, das ja eigentlich zum Model gehört, oder?

Die Frage ist jetzt, ich wähle z.B. über einen JFileChooser eine Datei, der Pfad wird in das JTextField eingetragen, das hat alles noch nichts mit einem Model zu tun, aber jetzt. Sollte ich jetzt den Pfad in einer 'Model-Klasse' sofort speichern, also bei jeder Änderung, die ich in der GUI-Klasse vornehme. Die Klasse, die dann mit dem Pfad irgendwann arbeitet, holt sich dann den Pfad aus dem Model, wenn ich z.B. auf einen Button klicke, der in der GUI-Klasse definiert ist.

Oder benutzt man gar keine 'Model-Klasse' sondern schickt die Daten einfach weiter wenn der Benutzer alles ausgefüllt hat. Ich hab mir nur gedacht, wenn ich z.B. eine Vorbelegung der GUI-Oberfläche habe, also schon vordefinierte Werte, die ich z.B. in einer XML-Datei abspeichere, dann lade ich die ja, um die Werte in die Oberfläche einzufügen. Hält man z.B. diese Werte in einer 'Model-Klasse' oder direkt in der GUI-Klasse.

Also ich weiß nicht ob es jetzt klarer geworden ist, was ich meine, ich hoffe einfach mal.

 

[bygones]

ist der Pfad etwas, was persisten sein muss, etwas was gespeichert werden soll ? oder einfach etwas temporäres, das gerade im moment gebraucht wird ?

Das Model stellt grundlegende Daten für die Applikation da. In meinen Beispiel in der FAQ mit der Wetterstation sind die Wetterdaten ja das Model. Würde man in der GUI eine Datei über den FileChooser öffnen, die die Daten gespeichert hat oder in die man die Daten speichert, so hat diese Angabe nix mit dem Model zu tun und muss daher auch nicht gespeichert werden....

 

[Elephant]

Also, so richtig persistent ist der Pfad nicht, da ich ihn nur brauche um die Datei einzulesen. Es ist nur so, dass während der Benutzer noch Eingaben machen kann, schon auf die Datei zugegriffen werden soll um z.B. schon einige Felder der Oberfläche auszufüllen je nach dem was in der Datei steht oder um einige Elemente zu 'disablen'. Wenn der Pfad während der Eingabe wieder geändert wird, müssen die Werte dann jeweils wieder geändert werden. Deswegen würd ich gerne wissen, wo diese Werte gespeichert werden sollten und wo die Änderungen berechnet. Direkt in der GUI-Klasse oder woanders.

 

[bygones]

für mich klingt das nach GUI Part... ich seh nicht, dass die Informationen zum grundlegenden Modell gehört. Es geht hier darum, ein GUI Information für späteren Nutzen zu halten. Ich seh jedenfalls nicht, was das mit einem Datenmodell zu tun haben sollte

 

[Elephant]

Ok, danke auf jeden Fall, für Deine Antworten.
Mit dem ganzen MVC und Programm-Design steh ich noch auf dem Kriegsfuß.

 

[CelikBlek]

Hallo,

Also die View 'beobachtet' ja das Model und wird bei Änderungen benachrichtigt. Darf nun die Klasse, die als View 'benutzt' wird (also eine GUI-Klasse, die die Swing-Oberfläche erstellt) über getter-Methoden auf die Daten des Models direkt zugreifen und sich die geänderten Daten holen oder muss dies über den Controller geschehen oder ganz anders?

Die View-Klassen registrieren sich bei Bedarf in den Model-Schicht-Klassen um bei Veränderungen benachrichtigt
zu werden (Observer-Architektur).
Sie können Methoden wie z.B. getElementAt aus der Model-Schicht aufrufen.
Die View-Schicht ruft niemals Methoden direkt beim Control auf, dazu wird ausschliesslich
die ActionListener-Architektur benutzt. Dazu müssen die View-Klassen ohnehin
erweitert werden, was eigentlich vermieden werden sollte.
Die einzige Aufgabe der Präsentationsschicht liegt darin, die fachlichen Objekte anzuzeigen
und einige Nutzerereignisse wie Mouse-, Window- und KeyEvents zu steuern. Sie
kennt keine Dialogabläufe und deren Abhängigkeiten zueinander.

Die Steuerungsschicht(Control) steuert den Programmablauf und entscheidet welche Sicht aufgerufen
werden soll.
Die Klassen der Controller registrieren sich, sowie bei View auch, beim Model um bei
eventuellen Ver¨anderungen benachrichtigt zu werden.

Das Model enthält die persistenten Daten und hat Zugriff auf die physikalischen
Speicher wie beispielsweise auf Datenbanken oder Legacy Systemen. Sie kennt keinen
der beiden anderen Schichten und ruft niemals direkt Methoden in deren Code auf. Bei
einer Änderung von Daten werden die registrierten Klassen der View oder Control über
die jeweiligen Event-Klassen benachrichtigt und ausschliesslich die ModelListener Architektur
benutzt. Die darzustellende Daten werden der Präsentationsschicht in Form
von Fachobjekten zur Verfügung gestellt.

 

[Elephant]

Die View-Schicht ruft niemals Methoden direkt beim Control auf, dazu wird ausschliesslich
die ActionListener-Architektur benutzt.

Mmh..., also ich glaub ich hab auch schon in MVC-Beispielen gesehen, dass in der View-Schicht direkt Methoden vom Controller aufgerufen werden.

 

[SnooP]

Das halte ich für weniger effektiv, weil dann ja Code in der View-Schicht geändert werden muss, wenn ich meinen Controller ändere!
Das tolle ist ja gerade, dass alle drei Schichten völlig unabhängig voneinander entwickelt werden können - zumindest M und V - der C verknüpft beide und vermittelt nur... das bedeutet, dass der Controller Listener für alle möglichen Events sein kann... auch ein eigenes Event-Modell kann dabei verwendet werden, falls das notwendig sein sollte... z.B. wenn man den Events teilweise komplexere Objekte oder Informationen mitgeben möchte...
oder aber man nutzt - wie schon erwähnt - das Observer pattern, wo sich alle View-Elemente bei dem Controller-Observer registrieren...

 

[CelikBlek]

Das tolle ist ja gerade, dass alle drei Schichten völlig unabhängig voneinander entwickelt werden können

Die Beschreibung von snoop finde ich :toll:. Das ist die wichtigste Aspekt bei der Sache. Indem dafür gesorgt wird, dass C nur Abhängigkeiten zum M kennt. Somit sin MVC nicht mehr zyklisch voneinander abhängig.
Ein Beispiel dafür im Java-Welt ist z.B. Swing. Hierbei ist das meiste schon gegeben. Es ist einfach genial aufgebaut. Die View Komponente sind bereits im Form von Widget's vorhanden. Vom Programmierer muss "lediglich" das Control und die Model gebaut werden. Die Kommunikations-Methoden (Interfaces) liegen bereits vor (ModelEvent, SelectionEvent usw.). MVC wird oft zitiert, aber selten richtig gemacht.

 

[Elephant]

Also ist praktisch der Controller nur Listener auf Model und View und kennt aber die Methoden im Model, die dann dort etwas ändern können? Und View ist nur Listener auf Model?

Edit:
Mir ist noch was eingefallen wegen der Unabhängigkeit. Also View ist Listener auf Model. Wenn sich im Model etwas ändert, wird View benachrichtigt. Wie kommt jetzt View an die neuen Daten? Wenn es ganz unabhängig sein soll vom Model, kann sich die View ja eigentlich nicht die Daten vom Model mit z.B. getter-Methoden holen. Also müsste der Controller die Änderungen holen und an die View weiterreichen. Dann braucht die View aber keinen Listener auf das Model.

Muss es also heißen, Controller ist Listener auf View und Model. Er kennt außerdem die setter und getter-Methoden von View und Model und reicht die Änderungen immer von View zu Model und vom Model zum View?

Das wird aber in den meisten Beispielen, die ich bis jetzt gelesen hab, nicht so gemacht. Oder ich habs einfach immer noch nicht kapiert. :? Irgendwie bin ich jetzt etwas durcheinander. ???:L

 

[bygones]

komplett unabhängig kann es natürlich nicht sein, schließlich muss die View ja wissen, was sie anzeigen soll....

es geht hier v.a. um eine Assoziation die nicht vorhanden sein soll, eine Independence darf und muss sein !

 

[CelikBlek]

Wie kommt jetzt View an die neuen Daten?

View ist registriert bei Model und kann somit bspw. getElementAt() aufrufen. Das bedeutet ja nicht, dass es abhängig ist. Und Control entscheidet welche View aufgerufen wird. Sie kontrolliert die View.
Nochmal die Abhängigkeiten:
Registrierungen
Control: registriert sich per ActionListener bei View und per ModelListener bei Model
View: registriert sich per ModelListener bei Model
Model: registriert sich nirgends !!!

Benachrichtigungen
Control: Steuert die View. Kennt dessen Abhängigkeiten
View: Ändert sich hier was bekommt es Control mit, weil er registriert ist.
Model: Ändert sich hier etwas bekommen es beide mit.

Die einzige Aufgabe der View liegt darin, die fachlichen Objekte anzuzeigen
und einige Nutzerereignisse wie Mouse-, Window- und KeyEvents zu steuern. Sie
kennt keine Dialogabläufe und deren Abhängigkeiten zueinander.

Die Steuerungsschicht steuert den Programmablauf und entscheidet welche Sicht aufgerufen
werden soll. Die Klassen der Controller registrieren sich, sowie bei View auch, beim Model um bei
eventuellen Veränderungen benachrichtigt zu werden. Controller-Klassen können Methoden
wie getElementAt oder auch addElement der Modellschicht aufrufen. Um zusätzlich
bspw. auf einem Knopfdruck reagieren zu können, registrieren sich die Klassen der Controller
auch bei den jeweiligen Views.
Wichtig !
Das Control kennt nur Abhängigkeiten zum Model, damit sind MVC nicht
mehr zyklisch voneinander abhängig. Dies ist bei Java Swing enorm wichtig, da Swing-
Controls nicht threadsicher implementiert sind.

 

[Elephant]

Ok, ich glaube es wird langsam klarer. Nur hier steh ich noch auf dem Schlauch

Das Control kennt nur Abhängigkeiten zum Model, damit sind MVC nicht
mehr zyklisch voneinander abhängig. Dies ist bei Java Swing enorm wichtig, da Swing-
Controls nicht threadsicher implementiert sind.

Was genau bedeutet den Abhängigkeit? Also ist es nicht so, wenn z.B. in der View-Schicht ein Textfeld unter einer bestimmten Bedinung 'disabled' sein soll, dann steuert das der Controller und ruft in der View eine Methode auf, die das Textfeld disabled. Die View steuert das nicht selbst, da sie nur Daten darstellt, aber nichts mit der semantischen Bedeutung zu tun hat, sie weiß also nicht wann das Textfeld disabled werden soll, erst wenn es der Controller sagt. Also sind doch irgendwie View und Controller abhängig voneinander.

Und noch eine, wahrscheinlich dumme, Frage. Was genau bedeutet

Die darzustellende Daten werden der Präsentationsschicht in Form
von Fachobjekten zur Verfügung gestellt.

Was sind diese Fachobjekte, packe ich die Daten, die die View-Schicht braucht um sie anzuzeigen, in ein Objekt und übergebe das z.B. bei notifyOberservers?

Also ich hoffe die vielen Fragen nerven nicht zu sehr, ich würde das nur gerne besser verstehen. Danke für eure Hilfe.

 

[Elephant]

Noch eine kurze Frage.

Wo wird was erstellt. Ich habs oft so gesehen:

Eine Hauptklasse erstellt Model und View und übergibt dem View das Model. View erzeugt Controller und übergibt Model und View (also sich selbst) an ihn. <- ist das so richtig? Irgendwie wäre dann ja der Controller auch schon wieder sehr abhängig vom View und würde sich in dem Fall nur um ein View kümmern.