[java] Samenwerking Struts en Hibernate, de beste strategie

[-FoX-]

Eén van de meest redundante zaken aan Struts zijn zonder twijfel de ActionForms waardoor eigenlijk het originele MVC omgebuigd worden in MVFC (model/view/(action)form/controller). Nu, omdat dit ook door de Struts ontwikkelaars als extra overhead aanzien werd, werden de DynaActionForms tot leven geroepen. Waar ik dan ook zoveel mogelijk mee probeer te werken.

Het probleem dat ik heb, zit hem niet zozeer in de ActionForms, maar eerder in de combinatie Struts & Hibernate. In de formulieren in mijn web-applicatie, kunnen de gebruikers deze formulieren opstellen door het selecteren van een aantal waarden in drop-down boxen. De waarde die hier gekozen wordt, is natuurlijk niet het object zelf.. maar simpelweg een domme ID representatie .

In de Hibernate mapping files, liggen de many-to-one relaties wel goed. Maar deze relaties zijn gebaseerd op objecten, niet op ID Strings.
Welke stappen nemen jullie om deze ID Strings om te vormen tot volledige objecten?

De manier die ik nu gebruik is de volgende:
* Gebruiker submit het formulier.
* Het formulier komt binnen in mijn Struts action; ik lees al deze velden uit en voor de geselecteerde ID's haal ik eerst de objecten op uit de relationele DB (dus telkens met een get(ID)).
* Als ik deze objecten terugkrijg, link ik deze aan het hoofd-object en stuur ik dit object naar de DAO (waarna het object gesaved wordt).

De aanpak die ik hier gebruik, vereist dan wel verschillende keren een call naar de DB alvorens het échte object gepersisteerd kan worden.

Nu heb ik deze aanpak weer eens gebruikt; maar bekom nu volgende exception:

NonUniqueObjectException: a different object with the same identifier value was already associated with the session

Graag had ik jullie ervaringen gehoord ivm deze manier van aanpakken. En eventueel op welke manier ik de vorige exception kan vermijden ?

[Alarmnummer]

-FoX- schreef op zondag 22 mei 2005 @ 15:15:
Welke stappen nemen jullie om deze ID Strings om te vormen tot volledige objecten?

Wij hebben een HandleStringConverter die ieder entiteit naar een string om kan zetten en bepaalde strings weer naar een entiteit.

[zneek]

Alarmnummer schreef op zondag 22 mei 2005 @ 15:22:
[...]

Wij hebben een HandleStringConverter die ieder entiteit naar een string om kan zetten en bepaalde strings weer naar een entiteit.

En dat in combinatie met een wrapper object die volledig zelfstandig de handleStrings uit de request ombakt naar entities in het te vullen gewrapte object.

[-FoX-]

De NonUniqueObjectException kwam er doordat ik in mijn mapping een cascade="save-update" had zitten.. Ik heb deze verwijdert en krijg deze exception nu niet meer. Al kan ik er niet direct een rede op plakken, iemand een idee?

De HandleString aanpak is nog niet zo slecht. Ik ga er zeker eens naar kijken! Zelf had ik er al aan gedacht om een converter class'je te schrijven die afhankelijk van het ingegeven ID, het ID zou omzetten naar het bijhorende object (adhv session.load()), maar deze aanpak is misschien wel beter omdat je dan adhv reflection je objecten kan bekomen.

[momania]

-FoX- schreef op zondag 22 mei 2005 @ 15:46:
De NonUniqueObjectException kwam er doordat ik in mijn mapping een cascade="save-update" had zitten.. Ik heb deze verwijdert en krijg deze exception nu niet meer. Al kan ik er niet direct een rede op plakken, iemand een idee?

De many-to-one/one-to-many mapping die je had is de oorzaak daarvan idd.

Waarschijnlijk heb je een object gehad met een collectie daarin, refererend naar een andere tabel via een foreign key or whatever.

Als je nu bijvoorbeeld je parent object creeerd en je vult van die parent de collectie met childs. Door de cascading, hoef je dan alleen je parent op te slaan en gaan je childs automatisch mee.
Hibernate gaat alleen tijdelijke id's maken voor die childs en daar krijg je die exception door.

Dit is vaak het geval waarbij je een composite id gebruikt voor je childs, waarbij die id dus vaak bestaat uit de primary key (id) van je parent object, plus een andere identifier.
Om deze exception te voorkomen, moet je een unsaved-id strategie gaan inbouwen, of aangeven.
Als attribute van de id of composite-id tag kan je dan het volgende meegeven: unsaved-value='any'.
Dit is de meest simpele oplossing die vaak goed genoeg werkt

---

Het nu va die dyna forms heb ik zelf nog niet echt gezien moet ik zeggen. Ik kan wel situaties verzinnen waar het makkelijk, generiek zou kunnen zijn, maar ik begin af en toe toch wel een beetje voorzichtiger te worden met het gebruik van generieke dingen.
Ik vind ze te fout gevoelig, omdat alles op string basis gaat. Zelf maak ik dan liever wat meer specifieke action forms aan, waarbij iig duidelijk is waar de inhoud aan gerefereerd moet worden en dat gelijk duidelijk is wat voor datatypes het zijn.

---

Verder qua strategie is het moeilijk te bepalen eigenlijk. Ik weet niet precies hoe je datamodel eruit ziet voor dit stuk en of bijvoorbeeld de childs die je selecteerd statische gegevens zijn of niet. Anders zou je natuurlijk goed gebruik kunnen gaan maken van caching.
Dan haal je eigenlijk alleen je parent maar steeds uit de database om de child links te updaten. Die childs komen dan gewoon uit de cache.

Verder zou ik me niet al te veel zorgen maken om database activiteit. Door het gebruik van hibernate doe je al veel meer queries dan in een situatie waarin je zelf queries gaat schrijven.
Hibernate gebruikt alleen maar hele basic queries, waardoor hij er veel meer nodig heeft om data te verzamelen en/of op te slaan.
Deze queries gaan op een knappe DBMS (die ook al weer aan query caching doet) gewoon retesnel.

[ Voor 40% gewijzigd door momania op 22-05-2005 19:49 ]