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]
|