Also aus dem anderen Thread habe ich entnommen, dass Du ja Swing einsetzt. Das sehe ich durchaus etwas Problematisch, da Swing aus meiner Sicht vieles nicht direkt unterstützt was ich für eine saubere Umsetzung gerne hätte. Du wirst die Elemente daher nicht wirklich gut entkoppeln können fürchte ich.
Ein Tool, das Dir dann alles in eine Klasse wirft, verleitet dann dazu, dass man Controller Dinge in der View unterbringt. Da muss man aber dann strikt aufpassen und eben nichts in der Art machen. Wie es aussehen könnte möchte ich einmal auf die Schnelle versuchen zu skizzieren. Aber das kann nur oberflächig sein und es wird im Netz bestimmt deutlich bessere Ausarbeitungen geben ...
Die View zeigt Daten des Models an - so wie es schon
@mihe7 gesagt hat. Veränderungen / Eingaben werden entweder direkt im Model gepflegt (Da findet man bei anderen Technologien die Bindings.) oder die View weiss, was der Controller will und ruft es entsprechend auf. Das Letztere wäre aus meiner Sicht die mögliche Umsetzung des MVC Patterns mit Swing und würde folgenden Code ergeben:
- Daten werden über ein Model bereit gestellt. Das kann eine einfache Entity sein oder halt ein neue Klasse mit wichtigen Informationen.
- Der Controller selbst kennt die Details der View nicht! Der Controller darf also keine Abhängigkeit zu der View haben bezüglich Aufbau. Die einzige Abhängigkeit kommt durch das Model, das sozusagen der Vertrag ist zwischen Controller und View. Und der Controller bietet nach Außen Aktionen an. Da kann dann also etwas aufgerufen werden oder so ...
- Die View basiert auf einem Model. Die Daten aus dem Model werden einfach angezeigt. Da Swing kein Binding hat, hast Du hier dann in der Regel Code, der Daten aus dem Model entnimmt und diese in Controls anzeigt. Dann hat die View gewisse Aktionen und daher gibt es Listeners. (Im Idealfall wäre das einfach ein Binding hin zum Controller. Die Daten würden in einem Model zusammen gepackt und dem Controller mit übergeben. Ideales Beispiel sind da immer Webseiten. Die Daten des Formulars werden einfach mitgegeben. Oder der Controller bekommt gewisse Daten mit, die in der URL verpackt wurden oder so ... ) So ein Listener in der View kann also einfach sein:
a) Daten für dien Controller zusammen packen
b) Aufruf Methode im Controller.
Was da dann raus kommen kann ist:
- Model Klasse, die generell Daten der View hält, also auch Daten aus Eingabefeldern und so.
- Methode in der View, die Daten aus dem Model in die Controls schiebt
- Methode in der View, die Daten aus den Controls in das Model schiebt.
- Listener sind immer gleich also onSchoeneAktionButton(..) ruft erst updateModel() auf und dann controller.machSchoeneAktion().
Wie Änderungen an den Daten vom Controller an die View gehen, kann man sich dann noch überlegen. Üblich ist oft das Observer Pattern. Das Model kann einfach geändert werden und das bekommt die View dann von alleine mit. Du hast in der View einfach ein (oder mehrere) Event, das der Controller direkt oder indirekt triggern kann.
Oder die View hat eine (oder mehrere) update() Methode, die der Controller einfach am Ende der Aktion ausführen kann.
Ich bevorzuge dabei das Erste! Dadurch braucht der Controller keine Referenz mehr auf die View. (Evtl. erstellt er diese, aber das muss nicht zwingend sein) ...
Dann hat:
- die View eine Referenz des Models und wenn es Aktionen gibt, eine Referenz zu einem Controller.
- der Controller hat eine Referenz auf das Model (Und die View, wenn Model keine Möglichkeit bietet für Observer!)
- das Model ist dumm - das enthält nur die Daten und bietet Optionen für Observer an!
Aus meiner Sicht hat dieses MVC Pattern bei Desktop Applikationen gewisse Probleme und passen daher nicht wirklich. Darauf möchte ich aber nicht weiter im Detail eingehen. Statt dessen ist das MVVM Pattern besser geeignet. Aber da bietet Swing weiter nichts groß. Bei JavaFX wäre mvvmFX als Library eine gute Option. Aber das ist dann wieder ein anderes Thema ...
Das einfach einmal als meine pers. Sicht auf dieses Thema.
