What's the value-add over Ibatis DAO Framework??

[Loumeister]

I am trying to convince the rest of my team that Spring rocks! However, me just saying that won't be enough. :wink:

My reasons for using Spring over the iBatis DAO Framework is as follows:

• 1. I can leverage the getHibernateTemplate() to ease Hibernate code creation.
  
  2. I can write AOP interceptors to create point-cuts/advice dynamically inside my code (e.g., exception handling).
  
  3. I can leverage the SessionFactoryUtils to manage my session transparently without having to demarcate them in my business tier.
  
  4. The community around Spring is an excellent resource.
  
  5. Spring provides extensibility in the area of transaction handling, MVC, etc. (although this is *not* a primary concern for us since we're using CMT and .NET, respectively).
  
  6. Others...

Note that this is not a slam on iBatis, but it's just that Spring brings more to the table especially with the AOP support. iBatis is very elegant, but I think the framework is more of an extension of their SQLMaps. Even the iBatis site recommends Spring...wtf!

Thanks,
Lou

[irbouho]

Well, I think we are talking here about two things that are very differents.
1. Spring is not a remplacement to iBatis (if we do not consider JDBC abstraction layer of course). You can still use Spring with iBatis: Spring builds an abstraction layer over iBatis (much like the iBatis DAO but more powerfull ). Using Spring integration for iBatis to build DAO is what iBatis web site recommends.
2. getHibernateTemplate() is completely an other history: you may use it if you decide to develop your application with the Hibernate/Spring stack.

1. I can leverage the getHibernateTemplate() to ease Hibernate code creation.

this is also true for Spring/iBatis, you need however to use classes from org.springframework.orm.ibatis package.

3. I can leverage the SessionFactoryUtils to manage my session transparently without having to demarcate them in my business tier.

declarative transaction demarcation is also possible / recommended when using Spring/iBatis.

Even the iBatis site recommends Spring...wtf!

As I said, the web site recommends Spring/iBatis integration over iBatis DAO, not considering Spring as a remplacement to iBatis.

For more information on using Spring/iBatis, you can review jpetstore sample from Spring distribution.

[Loumeister]

Omar,

I'm specifically talking about the DAO Framework not the iBatis SQLMaps. I agree that Spring and iBatis SQL Maps compliment each other. The DAO Framework, however, is a lightweight DAO abstraction layer that can be use with SQL Maps, Hibernate, etc. just like Spring can, but you'd have to choose to use one or the other. Choosing between the two is proving tough for us.

Here's a link to the piece I'm talking about: http://www.ibatis.com/common/dao.html

Thanks for your input,
Lou

[Juergen Hoeller]

Well, from my point of view, there are two main advantages of Spring's data access abstraction:

1. There's pre-built support for numerous data access strategies: JDBC, Hibernate, JDO, Apache OJB, iBATIS SQL Maps. Furthermore, there are various transaction strategies available. The iBATIS DAO framework just comes with, well, iBATIS SQL Maps support out-of-the-box.

2. Spring's DAO configuration and lifecycle management does not use custom means, but rather reuses Spring's core container. Therefore, you can apply the same configuration style throughout your entire middle tier (or even your entire application), not just for your DAOs.

I guess Clinton agrees in those respects: The iBATIS DAO page on their website recommends Spring too, as you noticed :-)

Juergen

[Loumeister]

I'm so excited...I got it approved by the architects and the rest of the team. Now our company will use Spring with Hibernate too...wahoo!

Thanks for your responses...