MVC- Design Frage

[java_beginner11]

Liebes Forum!

Ich habe den MVC-Pattern grundsätzlich verstanden und habe mir auch schon einige Beispiel durchgesehn bzw. selbst implementiert.
Leider wird der Pattern immer so erklärt:
Das Modell ist ein Objekt wie z.B. eine Person. Über getName, getNachname, etc. holt sich die View die Daten des Modells. (immer Primitive Datentypen).
Natürlich muss man, wenn Daten im Modell verändert werden, über den Controller das Modell informieren.

Was ich nicht verstehe, ist, wenn das Modell komplexer ist. Z.B. eine Personendatenbank welches durch ein Modell-Objekt repräsentiert wird, dass eine Liste von Personen enthält. Wenn ich nun auf der View Seite eine JTable mache und sich die View die PersonenListe vom Modell holt, dann werden die Änderungen ja direkt übernommen: sprich, man brauch die Model nicht informieren.

Ist das ein richtiges vorgehen oder darf man solche "Short-Cuts" nicht verwenden? Wie würde man so etwas richtig implementieren? Darf man Objekte an die View übergeben oder nur primitive Datentypen.

Bin für jeden Hinweis dankbar

 

[Thallius]

Also so wie du schreibst kannst du das MVC eigentlich nicht verstanden haben. Denn das essentielle am MVC ist, dass Model und View nichts miteinander zu tun haben. Durch die kapselnd der beiden Objekte wird ja erst die Universalität des Models erreicht. Ales läuft über den Controller. Der View fragt Daten beim Controller an. Dieser holt die Daten aus dem Model und gibt sie an das View. Werden die Daten im View geändert, dann sagt das View dem Controller Bescheid und dieser gibt das an das Model weiter welches die Änderungen übernimmt.

Dabei können die Daten zwar Objekte sein und du kannst auch das Design zunächst so wählen, dass komplette Objekte durchgereicht werden. Aberves muss halt so sein, dass wenn sich das Modell ändert, der View trotzdem weiter damit zurecht kommt und anders herum. Beaucht der View andere Daten, dann muss der Controller die Daten liefern.

Gruß

Claus

 

[java_beginner11]

Hallo!
Danke für deine Antwort.
Wenn ich mir auf java - The MVC pattern and SWING - Stack Overflow die Grafik ansehe (bei der ersten Antwort), so hat hier (wie auch in dem Buch beschrieben, wo die Grafik herkommt) die View eine Referenz auf das Model. Das Modell informiert die View unter Anwendung des Observer-Patterns (ist das Design, wo alles über den Controller läuft nicht Model-View-Presenter?)

Leider habe ich deine Beschreibung nicht ganz verstanden; Angenommen, ich bekomme ein Objekt über den Controller und gebe den in die JTable. Dort ändere ich in der JTable irgendein Attribut des Objektes. Nun ist ja bereits das Modell auf den gleichen Stand wie die View (da ich ja ein Objekt verwendet habe). Warum muss ich jetzt in Controller sagen, dass es sich verändert hat?

lg

 

[AndiE]

Ich denke, es ist vielleicht gut, das ein einem konkreten Beispiel zu erklären.

Ich nehme mal eine Verwaltung von Adressen an. Die Ansicht zeigt in Textfeldern die Daten, wie Name, Vorname, Ort, PLZ und Telefonnummer, und besitzt zum Navigieren mehrere Button( erstes, letzte, folgendes, vorhergehendes, 10 vor und 10 zurück).

Offensichtlich soll die Ansicht ja beim Start schon was anzeigen- den ersten Adresseintrag zum Beispiel. Wie kommt dieser in die Ansicht? Wenn wir auf die andere Seite sehen, dann haben wir ein Datenmodell, also ein Klasse Adressliste, die hier serialisierbar ist. Diese Klasse hat eine Liste von Objekten der Klasse Adresse und Methoden darin zu navigieren. Es gibt auch eine Methode, um ein Objekt der Klasse Adresse auszugeben. Dieses Objekt der Klasse Adresse ist es, was sich der Controler holt. Die Ansicht "kennt" also die Klasse Adresse und holt sich dessen aktuelles Objekt vom Controler. Die Attribute dieser Klasse sind es, die in den Textfeldern der View dargestellt werden.
Klickt jetzt der User auf einen Button (z.B. +10), dann feuert dieser, und ruft eine Methode im Controler auf. DIese ruft dann im Modell die Methode auf, die das Objekt, das 10 Einträge nach dem aktuellen Objekt steht, zum aktuellen Objekt erklärt, und erklärt gleichzeitig die Ansicht für ungültig. Daraufhin wird die Ansicht verworfen. Die Ansichtsklasse ruft wieder den Controler auf, der ihr das aktuelle Objekt der Klasse Adresse übergibt, und mit dessen Einträgen die Textfelder aktualisiert werden.