This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

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!

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.

Comment

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.

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 :-)