Leidiges Thema MVC *g*

[diggaa1984]

hiho,

hab ja nu schon ne Menge mitgelesen und nachgelesen und ja auch die FAQ und was es sonst so gibt, trotzdem schoss mir grad folgendes durch den Kopf:

Controller instanziiert seine View, und eventuelle weitere Controller für weitere Views
Ich habe ein MainFrame, darauf kommt ein CardPanel, damit ich die Oberfläche komplett wechseln kann. Auf dem CardPanel liegen auf kompletten Raum Panel, welche dann die jeweilige Ansicht (Buttons, Listen, Tabellen etc.) beinhalten. Nun habe ich gelesen das pro View nen Controller erzeugt werden soll. Sprich ich hätte einen Controller fürs MainFrame (mit Toolbar & Menüs welche über diesen Controller laufen würden?) und pro Panel auf dem CardPanel je einen Controller (welcher für die jeweiligen Ansichten zuständig ist). Wäre das so korrekt?
Theoretisch können in jeder Ansicht, und auch vom Menü aus die Daten verändert werden, sprich die Methoden dazu aufgerufen werde, sodass alle Controller die selben Methoden bereitstellen würden. So gesehen nur andere Ansichten, aber überall die gleichen Manipulationsmöglichkeiten.

Verzicht auf anonyme Klassen für Listener in den Views
Wie ich es mittlerweile verstanden habe und auch schöner finde, würde man die Listener-Implementierungen in den Controllern unterbringen. Sprich anonyme Klassen für Listener in den Views fallen weg.
Die Vielfalt der Datenmanipulation ist eher gering, sagen wir mal maximal 10 Möglichkeiten (sind bestimmt zu viel, Hinzufügen, Löschen Ändern von bestimmten Daten, etc). Auch würde nun die View kein Code mehr beinhalten der zB so aussieht: ... controller.foo() ... . Ich würde lediglich den Komponenten entweder direkt den Controller als Listener anbieten, oder eigenen Listenerklassen, die aber dann mit dem jeweiligen Controller zur View gekoppelt sein müssten.

Wie mach ich es nun am besten diese Listenerimplementierungen mit den Controllern zu koppeln. Gerne würde ich die Listener in extra Klassen unterbringen, der Übersicht halber. Interfaces, welche die Controller implementieren, würden sich weniger anbieten, da der Code in mehreren Controller recht redundant wär. Das die Controller von einem Listener/-SuperListener erben halte ich für weniger praktisch (wegen nicht vorhandener Mehrfachvererbung), aber ich hätte keinen redundanten Code in den Controllerklassen. Irgendwie gehen mir da die Ideen aus ???:L

was mir einfällt wäre folgendes:

public class MyListener extends .... implements .... {
    public void myActionPerformed(Controller specificViewController, Action e) {
        .... 
        specificViewController.foo();
    }
}

aber wie genau da nun was wovon erbt und implementieren muss weiss ich grad nicht. Das wäre die Variante das ich nen eigenen Listener an nen JButton binde, und dabei die jeweilige Controllerklasse in dem Listener parat hätte.
Selbiges müsste dann für Listen, Menüs und sowas alles gehen.

EDIT: ich würde dem Listener im Konstruktor den Controller anbieten, hätte also sowas:

fooButton.addListener(new MyListener(this.controller));

Müsste klappen oder? dann würde ich selbstverständlich den controller in obiger Methode wieder entfernen. Wenns blöd kommt müsste ich da noch schauen wegen Synchronisation, aber wenn das nur von der GUI ausgeht sollte nix nebenläufig manipulieren.

Was mir noch dazu einfällt:
Wenn ich die Listener extern halte, und ich möchte bspw auf Druck eine Buttons einen Text aus nem Textfeld zum Manipulieren der Daten nutzen, dann kennt der Listener keinen Verweis mehr auf die View, und kann somit kein Textfeld auslesen. Ich bräuchte quasi die Möglichkeit vor dem Auslösen der "actionPerformed" des Buttons ein Event zu schnüren was alle Informationen beinhaltet die jemals interessant sein könnten, im Sinne der Datenmanipulation. Dieses Event könnte man per "getLastEvent" aus dem Controller von seiner View anfordern.
Aber: wie könnt ich das performant genug machen, um nich bei jedem eingegeben Buchstaben gleich das Event zu updaten, denn ich weiss ja nie wann der Nutzer auf nen Knopp drückt.
Optimal wäre: Nutzer drückt Button, aber direkt vorm Eintritt in den Listener, schuster ich fix das Event mit allen nötigen Infos zusammen. Klingt für mich aber grad mal nicht machbar.

fireXXX-Methoden für die GUI
Ich muss ja nach erfolgreicher Manipulation der Daten, diese an die GUI weiterreichen. Dazu können das MainFrame und die Panels fürs CardPanel eine Schnittstelle "MyDataListener" oder dergleichen implementieren. Problem hierbei, das der Controller einer View, nur die Listener dieser View informieren kann, aber nicht die der anderen Views.

Kompromiss: Beim Wechsel der Ansichten lade ich die Daten neu, was aber ziemlich hässlich werden könnte bei größeren Datenmengen. ControllerView1 kann quasi keine Listener informieren die nur dem ControllerView2 bekannt sind.
EDIT ENDE

Ähm ja das sind so grad die 3 wesentlichen Punkte die mir einfielen
Sollte was nicht ganz klar sein, was ich gut verstehen kann, dann bitte nachhaken, bzw verbessert mich wenn ich total aufm Holzweg bin

Und wenn ihr nicht gestorben seit, erbitt ich eure Hilfe ^^ ... sry das so viel is :roll:

 

[SlaterB]

Sprich ich hätte einen Controller fürs MainFrame (mit Toolbar & Menüs welche über diesen Controller laufen würden?) und pro Panel auf dem CardPanel je einen Controller (welcher für die jeweiligen Ansichten zuständig ist). Wäre das so korrekt?

zumindest denkbar und oft korrekt

Theoretisch können in jeder Ansicht, und auch vom Menü aus die Daten verändert werden, sprich die Methoden dazu aufgerufen werde, sodass alle Controller die selben Methoden bereitstellen würden. So gesehen nur andere Ansichten, aber überall die gleichen Manipulationsmöglichkeiten.

Codewiederholung wäre aus meiner Sicht schlimmer als zuwenige Controller,
je nachdem wen und was es betrifft an Basisklassen denken oder an mehrere Controller-Typen,
so dass z.B. jeder unterschiedliche Card-Controller ein Objekt des Typs Main(-Frame)Controller hat, für generelle Aufgaben wie das Umschalten auf andere Cards
und/ oder einen anderen generellen Controller für allgemeine Programmaufgaben wie Datei laden
usw

Wie ich es mittlerweile verstanden habe und auch schöner finde, würde man die Listener-Implementierungen in den Controllern unterbringen. Sprich anonyme Klassen für Listener in den Views fallen weg.

aber hoffentlich hauptsächlich, weil die Views gar nicht WISSEN, was zu tun ist, sondern diese Logik im Controller steht,

wenn es nur darum geht, dass die Listener einzelne Operationen des Controllers aufrufen (starteAktionX()), dann könnten derart kleine Listener auch in der View stehen, da stören sie weniger

Auch würde nun die View kein Code mehr beinhalten der zB so aussieht: ... controller.foo() ... .

dann eben nicht

was mir einfällt wäre folgendes:

public class MyListener extends .... implements .... {
    public void myActionPerformed(Controller specificViewController, Action e) {
        .... 
        specificViewController.foo();
    }
}

nun wieder doch? ok, das ist nur der ActionListener an sich, der muss ja so sein,
ob anonym oder nicht, ob im Controller oder View..

na wenn das deine wichtigsten Fragen sind, dann hast du immerhin keine dringlicheren Probleme,
gutes Zeichen

ich bin jedenfalls für den View als anonymen Listener, man braucht etwa den JButton um darauf
addActionListener() aufzurufen, außerdem ist das viel Müll-Standardcode, der ist beim Standard-Code fürs Layout gut aufgehoben,
da ist Platz,

anonym sowieso, direkt am benötigten Platz definiert und keine zusätzliche Klassen

Wenn ich die Listener extern halte, und ich möchte bspw auf Druck eine Buttons einen Text aus nem Textfeld zum Manipulieren der Daten nutzen, dann kennt der Listener keinen Verweis mehr auf die View, und kann somit kein Textfeld auslesen.
[..]

habe ich nicht ganz genau verstanden,
aber ich halte es nicht für in Ordnung, wenn die View ständig ihre Daten versendet, nur damit der Controller nicht im Falle des Bedarfs nachfragen muss,
zuviel Arbeit

 

[diggaa1984]

gut ok, das mit dem auslesen von Daten aus der GUI geht natürlich doch mit den Events. Kann ja quasi nachdem die Listenerklasse die Controller-Methode aufgerufen hat, mit der Methode "getCorrespondingEvent(MyAction whatHappened)" dann die GUI Komponenten auslesen und ein Event zurückgeben. Muss ja nicht zwingend vorm Aufruf des Listeners sein. Das wär also gelöst

nun wieder doch? ok, das ist nur der ActionListener an sich, der muss ja so sein,
ob anonym oder nicht, ob im Controller oder View..

Das sollte eigentlich keine anonyme Klasse sein, sondern ne eigenständige ausgelagerte. :bae:

na wenn das deine wichtigsten Fragen sind, dann hast du immerhin keine dringlicheren Probleme,
gutes Zeichen

Joa also designtechnisch war das grad mal der Batzen der am schwersten wiegt ... Für die Logik eines Programmes gibts schon noch genug Wege.

Naja gut, aber im Prinzip scheint das ja alles ganz vernünftig zu sein.
Den Gedanken an eine Controllerhirarchie hatte ich auch schon, denkbar wäre ja zB das ich Views erstelle die nicht Manipulieren dürften, dann könnte man hier nen Controller mit eingeschränkten Rechten zuordnen etc. Trifft bei mir nicht zu, aber die Idee findsch gut.

Schade nur das ich mein bisherigen Code, wenn auch nur aus 7 Klassen bestehend, wieder umbauen darf, aber mach ich gerne solange am Ende ein sinnvolles Konzept rauskommt ... sonst würd ich ja nich derart nachfragen.
Aber alles Erfahrung die man sammeln sollte um später drauf zurückzugreifen :meld:


Vielleicht noch weitere Meinungen? bin für alles offen