Swing Data Binding und PropertyChangeSupport

[mvitz]

Hallo zusammen,

ich arbeite gerade ein einer mittlerweile recht großen Swing GUI. Zwischenzeitlich war die Überlegung, die GUI mit dem Model per DataBinding zu synchronisieren. Einsetzen wollte ich hierzu jgoodies-binding.

Diese Framework setzt allerdings darauf, dass die Modelklassen PropertyChange nutzen, zur Unterstützung kann man dort die Klasse Model erweitern, die bereits Unterstützung hierzu bietet. Ich möchte jedoch nicht, dass meine Domain (JPA2) Klassen von einer technischen Klasse erben, die ich im Endeffekt nur zur GUI Darstellung benötige und händisch in allen Domainklassen mit PropertyChangeSupport arbeiten möchte ich eigentlich auch nicht.

Wie löst ihr solche Situationen?

 

[Gast2]

Hallo zusammen,

ich arbeite gerade ein einer mittlerweile recht großen Swing GUI. Zwischenzeitlich war die Überlegung, die GUI mit dem Model per DataBinding zu synchronisieren. Einsetzen wollte ich hierzu jgoodies-binding.

Diese Framework setzt allerdings darauf, dass die Modelklassen PropertyChange nutzen, zur Unterstützung kann man dort die Klasse Model erweitern, die bereits Unterstützung hierzu bietet. Ich möchte jedoch nicht, dass meine Domain (JPA2) Klassen von einer technischen Klasse erben, die ich im Endeffekt nur zur GUI Darstellung benötige und händisch in allen Domainklassen mit PropertyChangeSupport arbeiten möchte ich eigentlich auch nicht.

Wie löst ihr solche Situationen?

Wie machst du dann die Notification, wenn sich was am Model ändert?
PropertyChanges hat nichts mit der GUI zu tun und erben musst auch nichts...

 

[mvitz]

Im Moment mache ich das ganze über eine Art Passive View Pattern.
Ich weiß, dass ich nichts erben muss, aber dann muss ich ja trotzdem in jedes Model Methoden zum Adden/Removen und eine Liste von Listenern hinzufügen, bläht imho mein Domänenmodell auf und gehört da auch nicht rein...

 

[Gast2]

Im Moment mache ich das ganze über eine Art Passive View Pattern.
Ich weiß, dass ich nichts erben muss, aber dann muss ich ja trotzdem in jedes Model Methoden zum Adden/Removen und eine Liste von Listenern hinzufügen, bläht imho mein Domänenmodell auf und gehört da auch nicht rein...

Klar gehört die Notification da rein wo sonst? Adden und Removen gehört in die Oberklasse...

 

[mvitz]

Technisch gesehen verstehe ich, dass das da rein gehört, ABER ich möchte meine Modellklassen gerne von technischen Abhängigkeiten frei halten und das geht dann nun mal nicht.

Außerdem empfinde ich es als mühsam in jeder Klasse immer wieder beide Methoden + die Liste von Listenern zu Programmieren. Möchte ich das umgehen, dann muss ich das in eine gemeinsame Oberklasse packen, von der dann alle meine Domainobjekte erben, was allerdings wieder dazu führt, dass ich in meiner Fachdomäne eine technische Abhängigkeit habe.

Vermutlich wäre für mich Presentation Model eine Möglichkeit. Aber ich wollte halt vorher mal generell fragen, wie hier die Leute das machen, es macht ja auch hier bestimmt nicht jeder gleich.

@SirWayne: Danke dir schon mal für die Antworten. Hätte allerdings trotzdem gerne noch antworten von anderen Forenmitgliedern.

 

[maki]

Ja, Presentation Model wäre ein Weg, ist halt etwas komplexer (DTOs inkl. DTO Assembler, zB. Dozer) und man hat bestimmte Dinge doppelt (Validierung etc.), dafür hat man Dinge getrennt, ist halt eine Frage dessen was man möchte/braucht.

Persistenz muss ja auch nicht zwingend in Domänenmodell, könnte man auch "invasive" nennen das so zu machen.
Wenn man vorhatte seine Entites direkt in die UI Schicht zu geben (die Entites dürfen dann halt nur dumme Datencontainer sein), kann man wohl den ganzen Schritt machen und den PropertyChangeSupport auch gleich fest ein bauen.

Wenn man sowieso ein "rich" Domänenmodell haben wollte und die UI in einer anderen VM läuft (wie bei JEE zB. mit JSF + EJBs der Fall), muss man DTOs verwenden, dann kann man der UI Schicht auch gleich ein eigenes Modell spendieren, bei einem dummen Domänenmodell braucht man das nicht.

 

[mvitz]

Wenn man die JPA Klassen mit Listenern bestückt, müssten diese allerdings transient sein, oder?

Zur Zeit sieht es so aus, dass die Domain-Klassen per JPA gespeichert/geladen werden und anschließend per REST an die Swing GUI übergeben werden.

Im Zuge der GUI (ich hab nicht so stark Swing Erfahrung) bin ich dann eben auf JGoodies Binding gestoßen, welches eben die PropertyChange-Sachen voraussetzt bzw. mit der Klasse "Model" eine Oberklasse anbietet, die den Umgang hiermit kapselt.