✔ MVC - Controller als ActionListener?

[ByeBye 154279]

Hallo,


Ich beschäftige mich seit kurzem mit dem MVC Pattern.
Habe das Prinzip zwar verstanden, wollte jetzt aber noch gerne ein paar Meinungen hören,
wie ihr das i.d.R handhabt


Implementiert ihr das ActionListener - Interface in eurem Controller?

Sodass ihr in eurem Controller folgenden Code in etwa habt:

Controller(view, model){
   this.view = view;
   this.model = model;
   initAction();
}

public void initAction(){
   if(xxx.getActionCommand().equals("")){
      System.out.println("");
   };
....
}

Oder ist euer Controller eine normale Klasse, in der ihr die einzelnen ActionListener hinzufügt?

Controller(view, model){
   this.view = view;
   this.model = model;
   initListener();
}

public void initListener(){
   view.setBtn1Listener(new Btn1Listener(view, model));
}

Beim zweiten Beispiel, müsste man (fast) immer die view und den/die Model(s) als Parameter mitgeben;
jedoch wäre der Code meiner Meinung nach sauber getrennt.

Bisher habe ich nur die zweite Möglichkeit angewendet.

Danke

bo

 

[Vereth]

Es existieren zwei MVC-Modelle: bei dem einen stellt der Controller nur die Verbindung zwischen Model und View her, die anschließend direkt miteinander kommunizieren, bei dem anderen läuft die gesamte Kommunikation über den Controller. Ich gehe jetzt nur auf das zweite ein, das ich persönlich aus folgenden Gründen bevorzuge:

• Es ist webfähig: die Website ist das Model, das die Daten an den Browser liefert, der als Controller fungiert. Dieser leitet sie dann an das View, nämlich das anfordernde Fenster weiter.
• Es ist sicherer: Zum einen kann der Controller z.B. Parametertest vornehmen, zum anderen kann er als Sicherheitsüberprüfungen, Filtermethoden u.ä. zwischenschalten.

Eine Website, die meinen Computer ungesichert steuert, ruft in mir ein unangenehmes Gefühl hervor; es erinnert mich an einen Virus.

Das prinzipielle Vorgehen läßt sich dann folgendermaßen darstellen.
Für das Model existiert eine Providerklasse, welche dafür zuständig ist, Daten einzulesen und zur Verfügung zu stellen. Diese stellt für die Kommunikation ein eventbasiertes Interface zur Verfügung, welches ermöglicht, sich bei ihm als Listener zu registrieren, um die Daten empfangen zu können. Sobald die Methode aufgerufen wird, mit der Daten angefordert werden, startet der Provider einen Thread, der die das eigentliche Retrieval durchführt, und kehrt dann unmittelbar wieder zurück. Sobald Daten eingetroffen sind oder Fehler auftreten, informiert der Thread den Provider, welcher dann das Resultat an den Anforderer per Event zurückliefert. Der Thread kann auch eine Tracker-Funktion erfüllen, der prüft, ob sich Daten geändert haben, und daraufhin den Provider informieren.
Das View ist im Normalfall der Initiator einer Anforderung. Der Controller empfängt per Event diese Anforderung, ermittelt die notwendigen Parameter, und entscheidet dann, an welchen Provider die Anfrage weiterzuleiten ist; er ruft dessen Anforderungsmethode auf und hat damit seine Arbeit getan. Ob und wie lange das View auf die angeforderten Daten wartet, entscheidet das View selber; auf diese Weise kann dann auch der Benutzer entscheiden, ob er die Verarbeitung abbricht, was dann per Event dem Controller mitgeteilt werden würde, welcher dann eine Provider-Methode aufruft, um den Anforderungs-Thread zu stoppen.
Der Provider braucht dabei nicht unbedingt ein Datenbank- und oder Datei-Reader zu sein. Bei JEdit beispielsweise, einem TextEditor, kann eine Datei in mehreren Fenstern angezeigt werden. Die Textdaten werden dabei in einer Buffer-Instanz gespeichert, welcher als Provider (ohne Threads!) fungiert und bei Änderungen Events versendet, welcher der Controller an die mit diesem assoziierten Views versendet. Diese Assoziationen werden vom Controller verwaltet, welcher das eine Event vom Provider 'spreadet', damit alle betroffenen Views up-to-date sind. Wird ein zusätzliches Fenster geöffnet, wird eine Methode des Providers aufgerufen, um den Momentanzustand des Buffers abzufragen und daraufhin per Methoden-Aufruf den neuen View korrekt zu initialisieren. Wird ein Fenster geschlossen, wird der Provider (also der Buffer) nur dann freigegeben, wenn keine anderen Views für ihn registriert sind und evtl. der Benutzer dem Speichern oder Verwerfen zugestimmt hat; nötigenfalls kann der Controller das Schließen des Views auch verhindern.