Zugriff auf PreferenceStore aus der Business-Logik-Schicht?

[Olel]

Hallo zusammen,

ich habe für meine Anwendung einen PreferenceDialog gebaut, um die zentralen Properties für den User konfigurierbar zu machen.

Nun möchte ich auf diese Werte teilweise in der Business-Logik-Schicht zugreifen. Wie kann ich das sinnvoll machen? Die Klassen PreferenceStore usw. liegen ja im Paket "org.eclipse.jface.preference", und darauf will ich natürlich nicht aus meiner BL referenzieren. Stehe ich auf dem Schlauch? Es muss da doch eigentlich eine "Standard-Lösung" geben.

Gruß,
Ole

 

[Wildcard]

Nimm den OSGi PreferencesService

*verschieb*

 

[Olel]

Hmm, schöne Idee, aber meine Anwendung ist keine RCP (OSGi)-Anwendung, sondern eine "normale" SWT/JFace Anwendung.

Da kann ich den OSGi PreferencesService dann nicht verwenden, oder?

Aber es muss doch auch eine andere Möglichkeit geben. Ich meine, die JFace-Entwickler werden sich doch auch gedacht haben, dass man die Settings, die man in der GUI-Schicht einstellt, nicht nur dort sondern auch in der Business-Logik braucht.

 

[Wildcard]

Hmm, ach so.... Dann habe ich das falsch verschoben.
Die JFace Entwickler haben mit Business Logik nichts am Hut, denn es ist eine grafische Bibliothek. In diesem Fall fehlt dir ganz einfach das passende Backend, denn JFace bezieht sich immer nur auf die UI. Ist ja kein Anwendungsframework.

 

[Olel]

Dann verschieb's doch bitte mal zurück ;-)

Ja, schon klar, dass JFace nur eine Grafik-Bibliothek ist, aber dennoch muss der Sinn so eines Frameworks, bei dem ein PreferenceStore angeboten wird doch sein, dass man diese Preferences dann auch im Backend nutzen kann...

 

[Wildcard]

Ein JFace Properties Store verwendet intern ein java.util.Properties Objekt. Mach dir doch einfach ein eigenes Interface das ohne JFace Referenzen auskommt.
Falls deine GUI einen IPreferencesStore benötigt, kannst du doch einen Wrapper um dieses Objekt schreiben das IPreferencesStore implementiert.

 

[Olel]

Gut, das wäre wohl eine Möglichkeit. Aber dann schreibe ich im Grunde eine eigene Implementation. Kann doch eigentlich nicht die beste Lösung sein.
Ich kann einfach nicht glauben, dass die JFace-Entwickler dieses Problem nicht bedacht und gelöst haben.

 

[Wildcard]

Was meinst du mit Bedacht? Die Klasse braucht ja keine GUI. Wenn du an dieser Stelle keine Abhängigkeit auf die JFace.jar willst, kannst du eben keine JFace Klasse durchreichen, so ist das eben. Wenn dich die Abhängigkeit nicht stört, kannst du die Klasse auch in deiner Business Logik verwenden.
Ist doch sowieso nichts anderes als ein aufgemotztes Properties Objekt

 

[Olel]

Du siehst mich jetzt ehrlich gesagt schon ziemlich überrascht. Du schreibst, die Klasse ((I)PreferenceStore) brauche keine GUI. Das ist nur die halbe Wahrheit. Dadurch, dass sie (natürlich) im package "org.eclipse.jface.preference" liegt, hat sie eine Abhängigkeit zu einem GUI-Framework. Jetzt kannst du natürlich sagen, dass man die Klasse einfach an die Business Logik durchreichen kann, aber damit schaffe ich eine Abhängigkeit der BL zu einem GUI-Framework und das geht nun mal gar nicht! Ist doch eine der ersten Regeln der Softwarearchitektur, dass es keine Abhängigkeiten von einer Schicht auf eine darüber liegende Schicht geben darf (Backend -> Business Logik, BL -> GUI).
Stell Dir vor, die GUI soll mal ausgestauscht werden oder es soll ein Web-Frontend für die Applikation entwickelt werden. Das wäre dann nicht möglich ohne die BL mit zu verändern.

Ich bleibe also weiterhin auf der Suche nach einer besseren Lösung. Hat vielleicht irgendjemand noch eine Idee?

 

[Wildcard]

Das ist doch genau was ich gesagt habe. Du kannst die Klasse durchreichen, wenn du bereit bist dir Dependency zu akzeptieren. Wenn nicht, dann darfst du es eben nicht.

Ich kann einfach nicht glauben, dass die JFace-Entwickler dieses Problem nicht bedacht und gelöst haben.

Wie soll denn JFace eine Lösung dafür finden das du JFace nicht verwenden willst? Ist doch irgendwo widersinnig.
Jetzt nochmal, was stört dich daran einen entsprechenden Decorator der das JFace Interface implementiert über ein Backend deiner Wahl (java.util.Preference/Properties,...) zu legen?
Dürften so ziemlich genau 10 Minuten Arbeit sein und ist eine vollkommen legitime und vor allem saubere Lösung.

 

[Olel]

Das ist doch genau was ich gesagt habe. Du kannst die Klasse durchreichen, wenn du bereit bist dir Dependency zu akzeptieren. Wenn nicht, dann darfst du es eben nicht.

Ok, so eine Abhängigkeit kann ich nicht akzeptieren und das sollte auch niemand anderes können. Deshalb ist das aus meiner Sicht kein (sinnvoller) Lösungsansatz.

Wie soll denn JFace eine Lösung dafür finden das du JFace nicht verwenden willst? Ist doch irgendwo widersinnig.

Man hätte es z.B. so implementieren können, dass ein PreferenceStore ein java.util.Properties-Objekt entgegen nimmt und dafür sorgt, dass dieses synchron zum PreferenceStore gehalten wird bzw. einfach eine Möglichkeit anbieten können von außen auf das Properties-Objekt (welches im Hintergrund ja eh verwendet wird) zuzugreifen.

Jetzt nochmal, was stört dich daran einen entsprechenden Decorator der das JFace Interface implementiert über ein Backend deiner Wahl (java.util.Preference/Properties,...) zu legen?
Dürften so ziemlich genau 10 Minuten Arbeit sein und ist eine vollkommen legitime und vor allem saubere Lösung.

Was mich daran stört? Das ich eine neue Implementierung des PreferenceStore schreiben muss. Das halte ich für absolut nicht sauber und zudem auch für erheblich mehr Aufwand als 10 Minuten. Hast Du mal geschaut, wie viele Methoden das Interface IPreferenceStore definiert? Der entscheidende Punkt ist aber, dass ich wie gesagt eine Implementierung schreibe, die es im Grunde schon gibt; inklusive Default-, Default-Default-Behanldung und Speichern etc.

 

[Wildcard]

Man hätte es z.B. so implementieren können, dass ein PreferenceStore ein java.util.Properties-Objekt entgegen nimmt und dafür sorgt, dass dieses synchron zum PreferenceStore gehalten wird bzw. einfach eine Möglichkeit anbieten können von außen auf das Properties-Objekt (welches im Hintergrund ja eh verwendet wird) zuzugreifen.

Das geht nicht, da der PreferenceStore PropertyChangeSupport anbietet. Wenn du das Properties Objekt nach aussen gibst ist es nicht mehr synchron zu den Events.

Was mich daran stört? Das ich eine neue Implementierung des PreferenceStore schreiben muss. Das halte ich für absolut nicht sauber

Natürlich ist das sauber, daher auch das Interface. PreferenceStore ist eine Default Implementierung.

und zudem auch für erheblich mehr Aufwand als 10 Minuten. Hast Du mal geschaut, wie viele Methoden das Interface IPreferenceStore definiert?

Das sind doch alles Einzeiler.

Der entscheidende Punkt ist aber, dass ich wie gesagt eine Implementierung schreibe, die es im Grunde schon gibt; inklusive Default-, Default-Default-Behanldung und Speichern etc.

Es gibt eine Default Implementierung, die aber nicht deinen Ansprüchen genügt, da du die Klasse nicht verwenden kannst ohne JFace.