Hibernate version: 3.2 Core + Annotations
Mapping documents: Entity Beans / hibernate.cfg.xml
Code between sessionFactory.openSession() and session.close(): Ich nutze keine sessionFactory
Postgres 8.2
________________________

Ich hab meine Anwendung in 3 Teilanwendungen aufgeteilt. Hauptanwendung ist mit Hibernate Einbindung, enthält das komplette Modell in Form der Beans sowie meine Business Logik (Controller).

Desweiteren habe ich 2 Teilprojekte, die beide als View dienen, unabhängig von eineander sind (eine Swing App, eine Struts Webapp), sich gegenseitig nicht kennen, aber beide auf die Hauptapp mit der Business Logik zugreifen und die auf dieses Projekt verweisen.

Mein Problem ist jetzt folgendes:
Ich muß in meinem Controller (der Business Logik) im Hauptprojekt auf Daten zugreifen wie
- angemeldeter User
- ...
Dafür hab ich mir eine Art Applikationsobjekt oder Sessionobjekt erzeugt (KEIN HibernateSession oder ähnliches). Nun gehe ich her und werfe dieses Objekt in Struts einfach immer in die HttpSession, da ich den Request und damit die Session ja von jeder Action aus im Zugriff habe. Im Gegensatz dazu habe ich in der Swing App einfach eine static Klasse draus gemacht, auf die ich auch von überall aus zugreifen kann (in Ermangelung einer Session in Swing). So wie ich das sehe, gibt es nur 3 Möglichkeiten, in der Swing App eine Session nachzubilden:

- in jeder Funktion das SessionObjekt als Parameter mitgeben (overhead, unpraktikabel)
- einen Thread programmieren und den dann im Stacktrace suchen und dort das Objekt rausziehn (Missbrauch?)
- das SessionObjekt statisch machen.

... wie macht mans richtig? Und zwar so, daß ich, egal welche View, den Zugriff auf so ein SessionObjekt immer im Controller (der Business Logik) im Zugriff habe?

Mir würden für die Swing Variante noch ein paar Ideen einfallen. Vorrausgesetzt mit 'statisch machen' meinst du eine Klasse, die nur statische Methoden hat.

Alternativen dazu:
- Singleton. Mittlerweile (oft zu Recht) als Antipattern verschrieen, aber sparsam und wohlüberlegt verwendet durchaus sinnvoll
- Dependency Injection: Alle Objekte, die eine solche Session benötigen, bekommen sie injiziert. Geht von Hand, oder z.B. per Spring
- Repository: Eine Klasse bauen, die das SessionObjekt herausgibt. Für die Klasse stellt sich dann natürlich das selbe Problem. In unserem aktuellen Projekt haben wir ein solches Repository, dass für ein Interface eine entsprechende Implementation rausgibt, die natürlich während der Initialisierung da einmal reingesteckt werden musste. Funktioniert gut.


Jens