After reading the Hibernate manual and some forum topics I'm sure that Hibernate is the way to go for our new project! But I still have some questions before I want to start implementing it.

The main problem is that I want to encapsulate the Hibernate specific code so that we can switch to another ORM tool when necessary. Although I already read several posts about this issue I still haven't found the perfect solution.

We have an application using a lot of object with a lot of relations between them. Depending on the requested JSP page (from Struts) I want to select only those objects necessary for building up the page. For example in some cases we need only the Company object, in other cases we need the Company and its list of employees.

One possibility I see is to initialize the Hibernate session in the Struts action and do some inserts/updates/deletes or selects. Commit the transaction and close the session.

But for scalability reasons we want to use a multi-layered architecture. In other words we want the Struts action to talk to a (stateless) session bean that will use hibernate to manage the persistence.

I always try (like most people I guess) to implement the use of a framework like Hibernate in a way that makes it possible to replace it with another framework in the future. This is why I

This has been discussed, in the end of 2003 and there is no perfect solution.
Basicaly, what I thinks is the best one :
- using DAO encapsulating explicit usage of hibernate especially HSQL queries
- opening and closing hibernate session before the process level usage using AOP or generated wrapper
(- implementing a session abstraction concept as in ORM which delegate to Hibernate)
- you cannot be abstracted of your ORM in the way it solve issues

the Spring Framework is an example of separation pattern while intensive ORM capabilities usage. Juergen will probably detail that ;-)

Thanx for your help!

I'm a bit late here, but good point, of course ;-)

Spring provides generic transaction management combined with generic DAO support. You can demarcate your transactions in a generic way in your business facades, without being tied to any particular data access tool. The actual transaction strategy is configurable: for Hibernate, HibernateTransactionManager or JtaTransactionManager would be appropriate.

If your DAOs are coded with Hibernate, the Hibernate Session will automatically get bound to the transaction. So if you rely on lazy loading, you can do that as long as the transaction is active - without dependencies on Hibernate in that transactional business code! On transaction commit, the Session will automatically be closed by Spring's transaction manager.

While Spring provides all of these services for POJOs, either programmatically or declaratively via AOP, it can also be used within EJBs. You simply need to demarcate a transaction with JtaTransactionManager as strategy there, in addition to EJB's CMT: This will automatically participate in the existing JTA transaction, but additionally bind resources like a Hibernate Session for the course of the sub-transaction.

Juergen
http://www.springframework.org
http://www.hibernate.org/110.html