Ich habe einen Controller und eine Ansicht mit vielen Kinderansichten mit Kindern mit Kindern. Beispiel: JPanels innerhalb von JPanels mit Schaltflächen und Feldern, die ein Controller an das Modell übergeben kann.
Der aktuelle Weg, den ich mache, ist die Instantiierung von "Controllern" in der Ansicht, die über Action-Listener verfügen und auf meine Modelle, die Singletons sind, zugreifen. Das funktioniert- Aber es ist definitiv nicht MVC.
Die Frage ist also - wie mache ich das?
Ist die einzige Möglichkeit, vom Controller zu verketten: mainview.getSubView (). getSubView (). getSubView (). setActionListener (neues AL ()); und: mainview.getSubView (). getSubView (). getSubView (). getSomeTextFieldText ();
Das erscheint äußerst unpraktisch [und ich kann die Vorteile dieser Methode nicht sehen]
Irgendwelche Tipps oder Anleitungen wären hilfreich. Kein Tutorial, das ich sehe, erklärt MVC mit Kinderansichten.
Nebenbei bemerkt - ich weiß, ich sollte die Ansichten und Modelle Observable / Observer verwenden - aber selbst mit diesen habe ich ein Problem mit der Einstellung von Aktion Listenern.
Ich denke, Sie machen einen Fehler, indem Sie eine "Ansicht" konzeptionell an einzelne GUI-Komponenten binden. Im MVC-Modell gibt es wirklich kein solches Konzept als "Subview".
Wenn Sie beispielsweise einen Frame mit vielen Panels und Subpanels und Unterkomponenten wie Schaltflächen usw. haben, ist das ganze Ding die View / Controller-Schnittstelle in MVC. Ihr Top-Level-Frame (oder eine Kapselung Klasse, vielleicht Ihre GUI hat viele Frames, ist es egal) würde die Schnittstelle zum Controller (über, sagen wir, Ereignisse) und die Ansicht (via, sagen, Listener). Genau wie Ihre UI angeordnet ist, wird dahinter abstrahiert. Stellen Sie sich Ihre gesamte Benutzeroberfläche als Black Box vor. Wie Ereignisse von den internen Komponenten ausgelöst / bereitgestellt werden, ist Teil der UI-Implementierung, und dies kann sehr gut mit Ereignisketten und Delegaten usw. verbunden sein - aber das ist nichts, was die Ansicht / Steuerung betrifft.
Sie haben also etwas wie (konzeptionelles Beispiel):
%Vor%Dann:
%Vor%Im Idealfall können Sie die Hierarchie Ihrer GUI vollständig überarbeiten, indem Sie einen völlig anderen Komponentenbaum und eine andere Organisationsstruktur verwenden. Wenn die Informationen über die GUI übermittelt werden, bleibt die Ansicht und unverändert Controller bleiben unverändert.
Sobald Sie sich an das MVC-Muster gewöhnt haben, können Sie hier und da Verknüpfungen verwenden (zum Beispiel sind die Ansicht und / oder der Controller in vielen Fällen nur Zwischenhändler für Ereignisse und die GUI selbst kapselt sich manchmal ein Die gesamte Controller- und View-Konzepte, die Sie mit einer GUI, einem Modell und einer Reihe von Event-Listener verlassen - die Swing-Event-Architektur ist ziemlich MVC in sich selbst, und Grenzen können unschärfer werden. Das ist ok. Aber es gibt keinen Grund, dass entweder die Ansicht oder der Controller über die Struktur und den Objektbaum in der GUI Bescheid wissen müssen - selbst in Fällen, in denen Controller / Ansicht nur abstrakte Konzepte anstelle von konkreten Klassen sind.
Manchmal kann MVC besonders unscharf werden, wenn man mit Swing arbeitet, weil man am Ende natürlich alles auf MVC-Art macht. Wenn man also versucht, der Architektur ein MVC-Muster aufzuzwingen, fragt man sich, warum das nicht funktioniert. Sie scheinen sich viel zu ändern (und es wird schwierig, die Vorteile zu sehen, weil Sie vergessen, dass Sie es bereits tun). Manchmal ist es eher eine Art von Denken als eine konkrete Art von tun .
Im Wesentlichen, jedes Mal, wenn Ihr Modell völlig unabhängig von Ihrer GUI ist, verwenden Sie eine MVC-Inkarnation.
Edit: Ich habe bemerkt, dass du dies auch mit "Beobachtermuster" markiert und es kurz erwähnt hast. Es ist erwähnenswert, dass das explizite Implementieren eines Observer-Musters für Swing-basierte GUIs, zumindest in relativ einfachen Anwendungen, nur eine redundante Abstraktionsschicht hinzufügt, da die gesamte Swing-API bereits grundlegend auf diesem Designmuster basiert (es ist das Ganze) Event - & gt; Listener-Subsystem).
Häufig habe ich festgestellt, dass etwas wie das Folgende gut funktioniert, wenn man das sogenannte Beobachtermuster verwendet, bei dem der Controller im Wesentlichen nur eine Sammlung von Ereignis-Listenern ist, wie:
%Vor%Und dann die GUI tut etwas wie:
%Vor%Aber es gibt viele Möglichkeiten, diese Katze zu häuten. In diesem Beispiel können Sie sogar, sobald Sie mit dem Konzept vertraut sind, und wenn es angemessen ist, eine Verknüpfung verwenden und den GUI-Konstruktor nur Listener registrieren lassen, die das Modell ändern. Dann wird der Controller, wie oben erwähnt, zu einem abstrakten Konzept.
Tags und Links java model-view-controller observer-pattern