-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 posts ] 
Author Message
 Post subject: More on best practices?
PostPosted: Tue Jul 12, 2005 2:29 am 
Newbie

Joined: Wed May 18, 2005 3:02 pm
Posts: 18
I've got a bunch of domain model objects which are fully persistent and don't have a single line of code devoted to persistence, which is just the way I like them. It makes testing and everything else about development so much easier.

However, much of the business logic for my app obviously DOES need to know about persistence. This isn't a huge problem, as I'll build an api package which contains business logic objects which know about persistence and perform actions on domain model objects. For example, a SecurityService object would have a login(String username, String password) method which would return a User object from the domain model.

I assume I'm not the first to go with such a structure. My question is - how do folks go about dealing with hibernate sessions, detached objects, and the like. Obviously, I can use the HibernateUtil pattern from the book which sticks a session in thread local storage. Assuming others have used this, what have you found to be the best way of maintaining consistency with regard to session maintenance? Always leave the session open and let the caller commit and rollback as necessary would seem to be the obvious mechanism. Another would be duplicate methods, one which leaves the session open, and another which returns a detached object and the session closed. Any other suggestions for dealing with this?

In the end, my api package will be used by a struts or spring based (I haven't decided yet, but my experience is all with struts) webapp to interface with users, so I can auto-commit sessions at the end of rendering the view in the worst case, but optimize my app to close it earlier where appropriate. That gives me maximum flexibility but will possibly scatter hibernate specific code throughout the webapp.

Anyone got any cleaner solutions?

--sam
[/i]


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jul 12, 2005 2:32 am 
Newbie

Joined: Wed May 18, 2005 3:02 pm
Posts: 18
An obvious alternative would be to put business logic right into my domain model objects. A static login method of the User object, for instance, but then I can't have code which utilizes the User object without a hibernate context, which makes testing more involved. I still have the problem with closing sessions in the webapp, of course.

--sam


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.