First of all, I want to say that I red the Java Persistence book and the
http://hibernate.org/42.html document.
I opened this thread hoping that Christian can answer me about a general question about the too-old-do-not-use-spring-stuff discussion.
I agree with Christian, I do not find so useful to hide the specific Hibernate Exceptions behind a generic Exception Hierarchy. So I do not use HibernateTemplate.
But as mentioned in the 42.html document "... To remove transaction demarcation from your data access code you might want to write your own interceptor that can begin and end a transaction programmatically (or even declaratively)....".
In the current documentation of Spring 2.0 they suggest a way to implement a DAO based on Hibernate3 API, where Spring role would be just to inject a SessionFactory.
Here is the example code:
Code:
public class ProductDaoImpl implements ProductDao {
private SessionFactory sessionFactory;
public void setSessionFactory(SessionFactory sessionFactory) {
this.sessionFactory = sessionFactory;
}
public Collection loadProductsByCategory(String category) {
return this.sessionFactory.getCurrentSession()
.createQuery("from test.Product product where product.category=?")
.setParameter(0, category)
.list();
}
}
In this way, they say, you can still use the Spring AOP to manage the transaction demarcation, without using any other Spring-Hibernate machinery a part the fact that the SessionFactory is injected by the Spring framework using the class LocalSessionFactoryBean (which, anycase, looking at the code, seems to use a standard Hibernate API).
In your experience, as an Hibernate expert, is it a satisfactory way of working if, for some reason, you are forced to use a Spring environment instead of Seam or EJB3? Do you know any problem encountered by people that used this approach?
As you can understand, I cannot formulate this question to the Spring people, as they would not, probably, point out any problem in a solution that they propose.
Thanks a lot
Marco Pancotti (Italy)
Login
FAQ
Search
