Hibernate, model/dao en reattachen

[MikeN]

Hoi,

Ik heb een applicatie waarbij het model deels bestaat uit Hibernate entities, en deels uit pojo's die in een andere datastore (Blackboard in dit geval) worden opgeslagen. De applicatie gebruikt eigenlijk alleen Hibernate als framework (en GWT, maar dat staat hier los van), en de bedoeling is dat er een zelf gekluste dao laag tussen de business/views en het model komt te hangen, om eea aan queries te centraliseren enz. Spring of andere frameworks worden niet gebruikt (is ook geen tijd voor om daar in te duiken).

Het probleem is dat de niet-Hibernate model objecten referenties hebben naar de Hibernate entities. Na het opnieuw inladen van de objecten uit de store (bv. serialized uit BB, ik ken het exacte opslagformaat niet), zijn de Hibernate objecten detached van de sessie en moeten ze opnieuw attached worden (in het geval van het opslaan van de gehele objecten) of moeten de hibernate objecten opnieuw opgevraagd worden (wanneer je bv. alleen de key opslaat in je niet-Hibernate model objecten).

De vraag is nu even waar ik dit het beste kan doen en hoe ik dit op een nette manier kan doen. Ik kan het model het allemaal zelf uit laten zoeken, maar in dat geval moet je _of_ direct Hibernate acties in je model opnemen, _of_ je model de dao laag aan laten roepen. Ik kan ook na het inladen van de niet-Hibernate model objecten (via de dao laag), de dao laag ook meteen de verschillende Hibernate objecten laten afhandelen. Alleen moet de dao laag hierbij precies weten welke Hibernate objecten zich in het model bevinden, wat de afhankelijkheden weer erg vergroot. Misschien is er nog wel een andere manier, waar ik nog niet aan gedacht heb.

Wat lijkt jullie een goede manier om dit op te lossen?

[NLxAROSA]

De oplossing waarbij je het model de Hibernate zaken zelf op laat halen brengt je in een spagaat: enerzijds is je model verantwoordelijk voor het afhandelen van persistentie (Hibernate gedeelte), aan de andere kant niet (het BB gedeelte, dit ligt als ik het goed begrepen heb bij de DAO-laag). Ik zou die verantwoordelijkheid (los van waar je die dan legt) op één plek beleggen. Dus of het model alles zelf laten regelen (dus zowel Hibernate als BB), of alles door de DAO laag laten regelen.

Dit, gecombineerd met het feit dat je al een DAO-laag hebt voor allerlei andere zaken, zou erop kunnen wijzen dat het handig is om dit gedrag in de DAO-laag te beleggen. Die hoeft daardoor niet per se kennis te hebben van de structuur van het model: als je zorgt dat alle Hibernate-entiteiten een gezamelijke subclass hebben of een specifieke interface implementeren, kun je daar op selecteren.

Uiteraard kan het andersom ook: het model alles laten regelen. Maar zonder je applicatie en model te hebben gezien vind ik het moeilijk om daarvan de impact te bepalen.

[MikeN]

Bedankt voor het meedenken.

Uiteindelijk ben ik volgens mij op een redelijke oplossing uitgekomen, mede doordat Blackboard vrij weinig aan opslag ondersteunt. Ik heb een aparte persistence klasse voor Blackboard geschreven, die reconstrueert de objecten (in dit geval user preferences en subscriptions op bepaalde zaken), en gebruikt daarvoor de DAO laag. De Hibernate objecten worden daarin opgehaald op ID, wat met een get() ook geen queries kost gezien er een proxy wordt aangemaakt.

Het model heeft zo uiteindelijk alleen referenties naar andere model klassen en is zich er niet van bewust of dat Hibernate klassen zijn of iets anders, en de DAO laag laat alles over aan de Blackboard persister klasse. Switchen van opslag kan zo uiteindelijk door gewoon een andere DAO laag ertussen te hangen, die op een andere manier de user specifieke zaken ophaalt.