CODEWITHSUNDEEP
javaspringhibernate
FrankD
FrankD

Reputation: 899

integrate hibernate with spring without spring dependency in dao

When we integrate hibernate with spring we normally implement annotation based approach use by @Repository spring annotation. I learned the purpose of going for it is, in order to eliminate the spring dependency in our dao and since hibernate3 support contextual session to manage sessions

@Repository
public class HibernateSpitterDao implements SpitterDao{

privateSessionFactorysessionFactory;

@Autowired
public HibernateSpitterDao(SessionFactory sessionFactory){
  this.sessionFactory=sessionFactory;
}

private SessioncurrentSession(){
  return sessionFactory.getCurrentSession();
}
...
}

For example if we do not use the annotation based approach our dao will directly depend of spring specific classes like need to extend the HibernateDaoSupport.

But even with the annotations still the DAO is depend on Spring know? because @Repository is spring annotation. We cant have a total independency with spring know? Its more like depending on a spring annotation is rather good than depending on a spring class, is it?

I was just thinking ok some time later we need to switch spring with some thing else. In that case if our DAO's has zero dependency with spring, we do not need to touch our DAO's at all know.

Upvotes: 1

Views: 873

Answers (2)

alfredaday
alfredaday

Reputation: 2068

I would say that the example you provided is not tightly dependent on Spring. The only Spring component you are using is the @Repository annotation, which 1) acts as a @Component and let's you component scan the class, and 2) makes your class eligible for data access translation (Source).

That's not coupling your implementation to Spring at all. Instead, you are using Hibernate's Session Factory and you are coupled to that. That's okay that your implementation is coupled with Hibernate.

In fact, that's the entire purpose of defining an interface and having different implementations of it. In this case, you have a SpitterDAO interface and a HibernateSpitterDAO implementation. If you decide in the future to utilize iBatis or Spring's HibernateTemplate or JDBCTemplate, you could write a different implementation.

Spring tries to stay out of your way for the most part. It's largely used as a container to manage dependency injection and really just coordinates how your code is "glued together". I think code gets tightly coupled with Spring when you have classes that implements things like ApplicationSessionAware and BeanPostProcessor, which I would try to avoid as much as possible.

And just because I wasn't sure if you knew the pros/cons between SessionFactory and Spring's HibernateTemplate, here is a great blog post from SpringSource comparing and constrasting them: http://blog.springsource.org/2007/06/26/so-should-you-still-use-springs-hibernatetemplate-andor-jpatemplate/

Here is a snippet of final suggestion from the blog post:

So in short (as the JavaDoc for HibernateTemplate and JpaTemplate already mention) I'd recommend you to start using the Session and/or EntityManager API directly if you're starting to use Hibernate or JPA respectively on a new project–remember: Spring tries to be non-invasive, this is another great example!

Upvotes: 0

pap
pap

Reputation: 27614

To achieve complete decoupling, you will have to move away from annotations, just as you already discovered. Either, you'll have to use the spring XML-based configuration, or you create a @Configuration class (aka java-based configuration) that builds up your bean factory.

I just want to make a comment on your thinking. Spending time on a completely de-coupled solution with the reason that "maybe sometime in the future we'll want to switch" sounds like a lot of time wasted to me. Do you have any reason to suspect or assume that such a switch will be done in the foreseeable future, or ever? There is a cost to your decoupling which is in clarity. Instead of easy-to-see annotations, you'll have to maintain XML-file(s) and/or configuration classes, which both tend to become pretty complex and hard to overview after a while.

Upvotes: 4

Related Questions