Passing information safely between Wicket and Hibernate in long running conversations
- by Peter Tillemans
We are using Wicket with Hibernate in the background.
As part of out UI we have quite long running conversations spanning multiple requests before the updated information is written back to the database.
To avoid getting hibernate errors with detached objects we are now using value objects to transfer info from the service layer to Wicket.
However we now end up with an explosion of almost the same objects :
e.g.
Answer (mapped entity saved in hibernate)
AnswerVO (immutable value object)
AnswerModel (A mutable bean in the session domain)
IModel wrapped Wicket Model
and usually this gets wrapped in a CompoundPropertyModel
This plumbing becomes exponentially worse when collections to other objects are involved in the objects.
There has to be a better way to organize this.
Can anyone share tips to make this less onerous?
Maybe make the value objects mutable so we can remove the need for a seaprate backing bean in Wicket?
Use the entity beans but absolutely make dead-certain they are detached from hibernate. (easier said than done)?
Some other tricks or patterns?
