MVC - Wo genau (am Model) registriert sich die View

[Gelöschtes Mitglied 6946]

Nachdem ich nun den halben Tag in den zig Threads zum Thema MVC hier ergebnislos gesucht habe, stell ich die Frage mal hier in den Raum. Die Tutorials und Beispiele, die ich gefunden habe, sind zumeist so klein, dass sie mein Problem nicht abdecken.

Ich habe eine Struktur von mehreren Klassen, die die Daten und damit das Model bilden. Prinzipiell ruft die View die gewünschten Daten ab und registriert sich "beim Model", damit dieses die View über Änderungen informieren kann. Nur stelle ich mir die Frage, wo genau sich die View registrieren soll - an jeder einzelnen Klasse des Models? So könnte die View sehr gezielt auf Änderungen reagieren, aber der Aufwand in den Model-Klassen selber wäre nervig, weil man entweder überall den Listener-Mechanismus implementieren müsste oder jedes (möglicherweise POJO) Objekt von Observable abgeleitet sein müsste, was auch nicht gerade das Gelbe vom Ei ist.

Oder wäre es sinnvoller, eine große, zentrale Model-Klasse zu bauen? Diese würde die registrierten Views verwalten und außerdem alle Veränderungen aufnehmen. Das würde aber bedeuten, dass ich eine riesige, aufgeblähte Klasse habe, in der ich die Setter sämtlicher kleiner Klassen vereinen müsste, damit ich auch jede Veränderung mitbekomme.

Keine der beiden Varianten will mir so recht gefallen. Eine andere Möglichkeit, dass der Controller die View über Veränderungen des Models informiert, will ich eigentlich nicht umsetzen, da das nur dann funktioniert, wenn es nur diesen einen Controller gibt - bei einem weiteren View-Controller-Paar zum Model gäbe es dann schon Probleme, wenn in einer Darstellung Daten geändert werden, die in einer anderen zu sehen sind.

Wenn jemand grundsätzliche Lösungsvorschläge oder gar Literaturen hat, dann immer her damit - beim groben Überblick im Buchladen hab ich nix gefunden, was sich direkt damit beschäftigt.

 

[Wildcard]

Folgendes System verwende ich gerne (für hierarchische Datenmodelle):
Jedem Modell Objekt (das eine visuelle Repräsentation hat) wird eine Controller Klasse zugeordnet (ein Controller kann dabei auch mehrere Modellobjekte übernehmen, aber nicht umgekehrt).
Die Instanzierung erfolg sinnvollerweise meistens über eine Factory (in welcher Form auch immer).
Die Controller melden sich (soweit erforderlich) als Listener auf ihren zugeordenten Modell-Objekten an und instanzieren eine View Komponente.
Das update der View und des Models übernimmt dann der Controller.

 

[byte]

Oder wäre es sinnvoller, eine große, zentrale Model-Klasse zu bauen?

Diese Lösung verwende ich in solchen Fällen: eine zentrale Fassade für das gesamte Datenmodell. Änderungen innerhalb des Datenmodells werden z.B. per Observer an die Fassade weitergereicht. Von außen braucht man nun nur noch auf der Fassade auf Änderungen horchen. Du hast natürlich recht, dass die Schnittstelle der Fassade ggf. ziemlich groß werden kann. Ich halte es aber trotzdem für sinnvoll, einen zentralen Zugriffspunkt auf die Objekte des Datenmodells zu haben, weil dadurch Seiteneffekte viel einfacher sichtbar werden bzw. die Kommunikation einfach übersichtlicher ist. Du musst ja nicht zwangsläufig jeden einzelnen Getter und Setter dort mit aufnehmen. Und ansonsten erstellen IDEs wie Eclipse ja auch gerne Delegates auf Anfrage, ohne alles per Hand einzutippen.

 

[Gelöschtes Mitglied 6946]

Danke für die Antworten. Ich werde mir da demnächst nochmal ein paar Gedanken zu machen - da es sich nur um einen (Gruppen-)Beleg im Studium handelt und das Programm letztendlich von ein oder zwei Personen benutzt und nicht mehr großartig verändert wird, ist es evtl. weniger entscheidend, welche der Varianten ich letztendlich umsetzen werde. Aber für spätere Projekte kann es definitiv nicht schaden, mal mehrere Herangehensweisen gehört zu haben