Tom Ziemer wrote:
Hi,
I have got a little problem with Hibernate - well actually it is only
partially related to it:
My app uses Spring + Hibernate (lazy loading), but should I return the
value beans (dom) from Hibernate to my Struts actions? If I do this,
I'd have to deal with LazyInitializationExceptions for collections
that have been lazy-loaded. In my opinion, this would be a horrible
design because the view would have to know about the data access tier.
On the other hand, I've read, that "DTOs are evil" - but how can I
solve this problem without DTOs?
I am sure, lots of you are using
Hibernate/{YOUR_LIST_OF_OTHER_GREAT_FRAMEWORKS_HERE}/Struts and I'd be
grateful for any help.
Thanks,
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Tom,
If the only problem you have is the LazyInitalizationException, then I
can suggest you at least approaches:
1. a hibernate session is opened by a Servlet Filter before eany
"struts" processing and si closed after "struts" processing ( I do it
like this )
2. you can have 1 hibernate session opened when the HttpSession is
created and closed wehn the HttpSession is closed. - in my opinion this
approach need more work to prepare but maybe is more correct ...moreover
you can keep alive DomainObjects in the HttpSession and not re-attach
them to the Hibernate Session on every new request.
The desicion is also depending on what transactional model you have
chosen (optimistic locking or pesimistic locking) and on some other
design desicions you've made already.
The avdantage of both approaches is that you have a valid session opened
during the whole "struts" processing cycle and you don't need to worry
about LazyInitalizationException.
Disadvantage is only that your view tier depends directly on your
persistance tier ... but is there a case when they are totaly decoupled?
I doubt ... and moreover sometimes small compomises should be done if
you know their price.
Rregards
Borislav
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
