MVC Design Pattern - Verständniss Fragen

[mephi]

Ich steh zwar mit GUIs auf Kriegsfuß, möchte jetzt aber mal ein Programm komplett mit GUI bauen. Nur fehlt mir noch etwas das Verständniss vom MVC..

a)
es sollen ja keine referenzen direkt übergeben werden und nur über addObserver gearbeitet werden?

b)
was mache ich am besten wenn ich eine Observable Klasse habe die viele verschiedene Daten beinhaltet. Wie teil ich das am besten über notifyObservers mit welches sich jetzt genau geändert hat? kann ich einfach das entsprechende objekt übergeben und alles in der dazugehörigen gui klasse auslesen?

c)
wer kennt überhaupt wen? die haupt controller-klasse kennt das frame und alle model objekte?
ich habe ein koordinatensystem aus "kacheln" soll die links außen angeklickt werden soll links eine neue eingefügt werden. dazu muss der controller doch die passende gui komponente kennen.. oder?

sorry wenn die fragen vll bissl blöd sind. aber mit gui konnte man mich bisher echt jagen

 

[byte]

a)
es sollen ja keine referenzen direkt übergeben werden und nur über addObserver gearbeitet werden?

Verstehe nicht, was Du damit meinst. Es gibt haufenweise Möglichkeiten, MVC zu realisieren. Observer-Pattern ist nur eine von vielen Möglichkeiten. Deswegen spricht man eigentlich bei MVC nicht von einem Pattern, weil es dafür nicht aussagekräftig genug ist. MVC sagt nur, dass Daten (Modell) und GUI (View) sich nicht direkt kennen sondern über Controller (z.B. Observer/Listener, Actions, Content/Label-Provider bei SWT, ...) gekoppelt sind. Hat den Sinn, dass man das Datenmodell auch ohne die View verwenden kann bzw. die View später noch austauschen kann. Streng genommen kann man auch das Datenmodell austauschen, aber meistens wird die View ja explizit für ein bestimmtes Datenmodell geschrieben. Von daher sieht man das häufig nicht so streng und schmeisst auch mal Controller in die View.

b)
was mache ich am besten wenn ich eine Observable Klasse habe die viele verschiedene Daten beinhaltet. Wie teil ich das am besten über notifyObservers mit welches sich jetzt genau geändert hat? kann ich einfach das entsprechende objekt übergeben und alles in der dazugehörigen gui klasse auslesen?

Der Observer kann alles auslesen, was das Observable beinhaltet. Musst dafür natürlich auf der anderen Seite explizit auf den Typ prüfen.

c)
wer kennt überhaupt wen? die haupt controller-klasse kennt das frame und alle model objekte?
ich habe ein koordinatensystem aus "kacheln" soll die links außen angeklickt werden soll links eine neue eingefügt werden. dazu muss der controller doch die passende gui komponente kennen.. oder?

view <---> controller <---> model

 

[EOB]

hi,

1. würd ich so nicht unbedingt sehen. mann könnte viel mit interfaces arbeiten, das macht alles sehr flxibel.

2. warum übergibst du nicht immer alles? wenns gleich ist, macht es ja nix...oder seh ich das falsch?

3. der controller ist im view drinne, kann also auch ruhig die view komponenten kennen. es kann durchaus auch mehr als ein controller sein, macht sogar sinn, denke ich. der view kennt kein model!

schau dir zum allgemeinen verständnis auch mal das MVC bei der wiki an.
ich denke es ist so am besten, dass du view und controller in den presentation layer packst. die controller der gui komponenten greifen dann zb über eine fassade auf das modell zu.

grüße

 

[Guest]

Ich würde das Vorgehen außerdem von der Größe bzw. Komplexität der Anwendung abhängig machen.

Im besten Fall sind View, Controller und Model komplett voneinander getrennt. Nur der Controller kennt View und Model, der Rest ist sich unbekannt:
- Als Controller könnte ein Listener dienen (z.B. abgeleitet von ActionListener). Ihm wird im Konstruktor z.B. ein Frame übergeben. Dort erfolgt auch die Registrierung des Listeners an der GUI-Komponente. So erfährt die GUI-Klasse nichts von seinem Controller
- Das Model wirft grundsätzlich Exceptions weiter und behandelt sie nicht. Das Exception-Handling ist Bestandteil des Controllers. Auf diese Weise kann man realisieren, dass auch das Model den Controller nicht kennt. Der Controller ruft das Model auf und erwartet ggf. ein Ergebnis oder eine Ausnahme und entscheidet über weiteres Vorgehen
- Der Controller übernimmt die Aufgabe der Datenbereitstellung in der View, weist also ggf. eine Bean zur Darstellung zu.

Auf diese Weise sind GUI-Klassen und der Model-Komplex unabhängige Module. Der Controller kapselt die Beziehungen zwischen den Beiden und sollte auch nichts anderes tun.