mvc-Modell: wenn views voneinander wissen sollen

[davidh38]

Ich löse das Problem, dass Views voneinander wissen, indem ich getter funktion für die viewlist im controller implementiere. Ist das ein guter Weg?

 

[Marco13]

Beschreib' ggf. mal genauer, wie dieses "wissen" aussehen soll (was genau sollen sie voneinander kennen?). Sofern das nicht über eine Eigenschaft des Modells passiert, würde es vermutlich vom Controller geregelt werden. Eventuell (!!!) wird dieses Wissen schon über eines der Modelle im GUI abgebildet (z.B. über ein ListModel oder SelectionModel oder ButtonModel bei Swing) - andernfalls könnte (!) man dieses "Wissen" dann wieder über ein Interface rausfaktorisieren, plakativ gesagt sowas wie

interface ViewKnowledge
{
    void doSomething();
}
class ViewA implements ViewKnowledge {}

ViewA viewA = new ViewA();
ViewB viewB = new ViewB();
viewB.setViewKnowledge(viewA);

Aber das ist so nur ein verschwommenes Bild in der Kristallkugel.

 

[davidh38]

Beschreib' ggf. mal genauer, wie dieses "wissen" aussehen soll (was genau sollen sie voneinander kennen?). Sofern das nicht über eine Eigenschaft des Modells passiert, würde es vermutlich vom Controller geregelt werden. Eventuell (!!!) wird dieses Wissen schon über eines der Modelle im GUI abgebildet (z.B. über ein ListModel oder SelectionModel oder ButtonModel bei Swing) - andernfalls könnte (!) man dieses "Wissen" dann wieder über ein Interface rausfaktorisieren, plakativ gesagt sowas wie

interface ViewKnowledge
{
    void doSomething();
}
class ViewA implements ViewKnowledge {}

ViewA viewA = new ViewA();
ViewB viewB = new ViewB();
viewB.setViewKnowledge(viewA);

Aber das ist so nur ein verschwommenes Bild in der Kristallkugel.

Das eine Fenster soll in Abhängigkeit von dem anderen Fenster platziert werden. Wäre deine Lösung dann die beste?

 

[Marco13]

Wäre deine Lösung dann die beste?

Das weiß ich nicht, und wer meint, das beurteilen zu können (bzw. zu wissen glaubt) möge sich bitte bei mir melden.

Bisher klingt es schon, als wäre es genug Abstraktion, wenn man dort ein "Window" übergibt, sofern man das Platzieren des einen (oder mehrerer???) Fenster nicht von einer eigenen Klasse übernehmen lassen wollte, die quasi ein "LayoutManager für Fenster" ist. Letzteres klingt IMHO allgemeiner und besser, aber ist auch nur geraten, solange du nicht genauer sagst, was du vorhast.

 

[davidh38]

Das weiß ich nicht, und wer meint, das beurteilen zu können (bzw. zu wissen glaubt) möge sich bitte bei mir melden.

Bisher klingt es schon, als wäre es genug Abstraktion, wenn man dort ein "Window" übergibt, sofern man das Platzieren des einen (oder mehrerer???) Fenster nicht von einer eigenen Klasse übernehmen lassen wollte, die quasi ein "LayoutManager für Fenster" ist. Letzteres klingt IMHO allgemeiner und besser, aber ist auch nur geraten, solange du nicht genauer sagst, was du vorhast.

Also ich habe ein Hauptfenster und ein Loginwindow. Das Hauptfenster wird in Abhängigkeit von der Auflösung platziert und das Loginwindow in Abhängigkeit von dem Hauptfenster. Jetzt ist die Frage, wie weiß das Loginwindow, wo sich das Hauptfenster befindet. Genau diese Information befindet sich in der "Hauptview" und an die muss das Loginwindow rankommen. Ist die Beschreibung präzise genug? Danke für deine Mühen bis jetzt!

 

[faetzminator]

Der Ersteller des Loginwindow kann doch einfach die Position setzen, da dieser eigentlich auch das andere Fenster kennen sollte. Wie hast du das implementiert?

 

[Michael...]

Ich sehe da jetzt nicht unbedingt einen direkten Bezug zum MVC.
Und warum sollte der Controller von einem Loginwindow (falls nicht schon so umgesetzt sollte dafür JDialog verwendet werden) wissen? Ob die Anmeldung über einen zusätzlichen Dialog oder direkt im Hauptfenster passiert sollte dem Controller und allen anderen Beteiligten völlig egal sein.

Ich würde da eher so vorgehen:
- View öffnet sich, sobald eine Aktion einen User bzw. einen angemeldeten User erfordet. "Meldet" der Controller der View, das eine Authentifizierung notwendig ist.
- View erstellt bzw. öffnet einen modalen Logindialog (Hinweis mit setLocationRelativeTo(...) kann man Fenster zentriert zu anderen Komponenten platzieren)
- Nach Eingabe der Nutzerdaten gibt die View diese an den Controller und schließt bei erfolgreicher Anmeldung den Dialog.

Natürlich kann man auch den Anwender unmittelbar nach Öffnen der View zur Authentifizierung auffordern - ist vermutlich einfacher umzusetzen.
Aber wie gesagt, der LoginDialog ist m.M ein View internes "Problem"

 

[Marco13]

Ist das Loginwindow nicht ohnehin ein (modaler?) Dialog mit einem "parent"? Man würde es einfach relativ zum parent platzieren, da braucht's gar keine ausgefeilten Tricks...

 

[Spin]

Ich habe mich jetzt sehr viel mit MVC beschäftigt und es gibt für Client basierte Anwendungen leider kein Kochrezept.

Soll jedoch eine Webanwendung mit Servlets programmiert gibt es genug gute und erforlgreiche MVC Konzepte. + HMVC für Module.

Persönlich finde ich es nicht schlimm, das jede GUI jede kennt. Das ist nach MVC erlaubt und sollte von Situation zu Situation selbst entschieden werden. Sicher braucht kein Login Fenster von einem Spiel Fenster oder Anderem Fenster wissen.

Interessanter ist das Handling der Controller und das Zusammenspiel mit anderen Patterns. (Observer)
Eine gute Anwendung in MVC ermöglicht die komplette GUI auszutauschen und das geht nur wenn man die Controller Logik kapselt und das in Listener. Diese kann man ohne Probleme einer anderen GUI hinzufügen. Ob die Views sich nun kennen oder nicht, hat mit MVC nichts zu tun, sondern mit der internen Semantik, ob das nach Ansicht des Betrachters Sinnvoll ist.


Siehe den anderen Beiträgen.

grüße spin

 

[davidh38]

Ich habe mich jetzt sehr viel mit MVC beschäftigt und es gibt für Client basierte Anwendungen leider kein Kochrezept.

Soll jedoch eine Webanwendung mit Servlets programmiert gibt es genug gute und erforlgreiche MVC Konzepte. + HMVC für Module.

Persönlich finde ich es nicht schlimm, das jede GUI jede kennt. Das ist nach MVC erlaubt und sollte von Situation zu Situation selbst entschieden werden. Sicher braucht kein Login Fenster von einem Spiel Fenster oder Anderem Fenster wissen.

Interessanter ist das Handling der Controller und das Zusammenspiel mit anderen Patterns. (Observer)
Eine gute Anwendung in MVC ermöglicht die komplette GUI auszutauschen und das geht nur wenn man die Controller Logik kapselt und das in Listener. Diese kann man ohne Probleme einer anderen GUI hinzufügen. Ob die Views sich nun kennen oder nicht, hat mit MVC nichts zu tun, sondern mit der internen Semantik, ob das nach Ansicht des Betrachters Sinnvoll ist.


Siehe den anderen Beiträgen.

grüße spin

Hallo Spin, danke für deine Antwort.
wenn du dich lange mit MVC beschäftigt hast, würde ich dich gern eine neue Frage stellen. Unzwar habe ich folgendes Problem

Ich habe ein Fenster, was den JPanel erweitert. Jetzt sind aber alle meine Views Erweiterungen von einer Klasse, die AbstractView heißt. Wie kann ich dafür sorgen, dass mein erweiterter Jpanel trotzdem von AbstractView erbt?

Meine zweite Frage wäre, ob du das mvc-Beispiel von der oraclehomepage kennst:
Java SE Application Design With MVC
und ob du weißt, ob das Observerpattern hier implementiert ist.

 

[Michael...]

Ich habe ein Fenster, was den JPanel erweitert. Jetzt sind aber alle meine Views Erweiterungen von einer Klasse, die AbstractView heißt. Wie kann ich dafür sorgen, dass mein erweiterter Jpanel trotzdem von AbstractView erbt?

Meine zweite Frage wäre, ob du das mvc-Beispiel von der oraclehomepage kennst:
Java SE Application Design With MVC
und ob du weißt, ob das Observerpattern hier implementiert ist.

In Java gibt es keine Mehrfachvererbung. Wenn Deine Klasse von AbstractView erben soll, könnte man ein JPanel als Instanzvariable, müsste aber entsprechende Methoden bereitstellen, damit man von aussen an das Panel kommt. Flexibler wäre man da mit einem ViewInterface.

Das Oracle Beispiel verwendet hier PropertyChangeListener als Nachrichtenschnittstelle zwischen den Komponenten. Was m.M. sehr abstrakt ist und für den Einstieg in MVC eventuell zu komplex. Ich würde hier eigene ListenerInterfaces verwenden, die etwas konkreter sind.

Noch ein Hinweis: View entspricht nicht unbedingt GUI.

 

[davidh38]

In Java gibt es keine Mehrfachvererbung. Wenn Deine Klasse von AbstractView erben soll, könnte man ein JPanel als Instanzvariable, müsste aber entsprechende Methoden bereitstellen, damit man von aussen an das Panel kommt. Flexibler wäre man da mit einem ViewInterface.

Das Oracle Beispiel verwendet hier PropertyChangeListener als Nachrichtenschnittstelle zwischen den Komponenten. Was m.M. sehr abstrakt ist und für den Einstieg in MVC eventuell zu komplex. Ich würde hier eigene ListenerInterfaces verwenden, die etwas konkreter sind.

Noch ein Hinweis: View entspricht nicht unbedingt GUI.

Danke für deine Antwort, was bedeutet denn "View entspricht nicht unbedingt GUI"? Was kann eine View noch sein?

 

[Spin]

Hallo,


deine Konsole kann doch auch Output anzeigen oder nicht ? 😉
In meinem letzten Projekt ist das Backend komplett in Java geschrieben und die Controller auch. Zudem wurd eine Flash-Client drauf gepackt. Da alles im MVC realisiert wurde, können wir ohne Probleme den Flash Client durch eine Java GUI wechseln.


Zu deiner Frage :
Es wurde schon gesagt, das Java keine Mehrfachvererbung bereit stellt, das muss es auch nicht 😉

Wenn deine AbstractView eine abstracte Klasse ist und diese vererbt wird an deine anderen Klassen, dann lass deine AbstractView von JPanel erben und deine anderen Klassen haben auch die Eigenschaften von JPanel.

public class MyView extends AbstractView {

}

public class AbstractView extends JPanel {

}

Was macht deine AbstractView überhaupt? Hat sie irgendeinen semantischen Hintergrund? Oder dient es lediglich für Struktur ?

Poste mal deine AbstractView ....Ich schätze das ein Interface auch funktioniert, außer du hast so viel Code der in jeder View gleich ist.

Zeig mal her jetzt 😛:bae:

grüße spin

 

[davidh38]

Hallo,




grüße spin

Alles klar, danke, das ist eine gute Idee. Meine Abstract ist wie gesagt aus dem Oraclebeispiel. Es hilft wahrscheinlich auch dabei, dass man leichter über die Views iterieren kann, wenn man verschiedene Views hat.