For a new project using Spring with JDBCTemplates, iBatis/myBatis or Hibernate?

Question

Hi there we are starting a project in which we have to make the decision between using Spring JDBCTemplates, iBatis/myBatis or Hibernate for our persistence layer. I am more or less familiar with the concepts from both of them but i am wondering what people currently tend to use.

My requirements are:

• keep everything as simple as possible
• easy learn and use
• high performance
• optimal developer productivity
• must be usable with Spring 3

As noted we would like to keep everything as simple as possible. My preference tends to lean toward iBatis/myBatis because it looks easier to use and we do not need a real OR Mapper. But i am really looking forward to learn from the guys that use these frameworks.

Answer 1

I advise you to have a look at minuteproject reverse-engineering solution for spring/hibernate/ibatis and also JPA(2), since it fulfill your development requirement. There is one thing that it does not generate (yet) is jdbctemplate.

Before opting for a technology, I will review all your points that fit in the minuteproject approach.

• keep everything as simple as possible: Let minuteproject generates for you the code you need for persisting in iBatis (sqlMaps), in Hibernate (hbm files), in JPA (orm file or annotated entities). But all the additional framework integration: spring configuration, a comprehensive DAO stack (not limited to basic CRUD ops). It can correspond from 20 to 40% of your Application artifacts and time.
• easy learn and use: your model becomes your technology tutorial! Learn from what has been generated. You can of course extend it for your specific need.
• high performance: in the minuteproject track for Spring/hibernate or Spring/JPA: minuteproject provides ehcache configuration generation integrated with orm product. It provides and avanced dao layer with tuned query that you just have to reference.
• optimal developer productivity: It helps you focusing on your real business and not all the tedious orm / dao tasks. It flattens the technology learning curve.
• must be usable with Spring 3: The spring artifacts are comptible with 2.5+

But the best one that can judge is you, so try it on you model. To have a quick overview of the possibility start /bin/start-console.(cmd/sh), point to your database and chose a generation track. It should normally take a few minutes if your database is (mysql, db2, oracle, hsqldb have default value such as hibernatedialect preset). To go more advance use the configuration (it is for all db).

Regarding to which technology to use, personally I have production experience with all of them, but I would consider that the bidirectional aspect of orm frameworks such as hibernate is a strong point over unidirectional sqlmap. It saves configuration and graph navigation is intuitive.

A goody: Escaping special character such as ', is including in orm frameworks. And this is a problem you would commonly face while performing native sql in sqlmap such an insert of a lastname = 'o'hara'...

I would go for Hibernate (among the choice you mention), but go for JPA2 (if you would have included it). If you want real extra productivity integrate querydsl for compilable criteria API in it.

Answer 2

I've worked with Ibatis and Hibernate. Ibatis is straightforward and simple. Hibernate can get complicated if you're not careful, but it does a lot for you. spring-jdbc is better than raw JDBC.

Hibernate's biggest advantage is being able to map to different databases. You can even turn off schema prefixes. You have options like using an in-memory database for testing, or having developers use local databases different from the production target (for instance if you're targeting Oracle and licenses are a problem), or being able to target multiple databases. Swapping out id generators is easy with Hibernate. With Hibernate native SQL is an option, but with Ibatis there is no choice.

Also it is hard to impossible to keep the Ibatis mapping files DRY. If you have multiple queries with different where clauses, cut-n-paste will result. With Hibernate there is nowhere near as much duplication.

Both Ibatis and Hibernate have a declarative caching mechanism, by the way. Hibernate's is much more involved, of course.

spring-jdbc shares all the disadvantages I've listed for Ibatis. In addition I don't think it has a caching mechanism. its main benefit is that the JDBC objects are not as well-hidden, so you can get direct access to them more easily if you need it.

Spring integrates with all three alternatives, spring support is not a differentiator.

One more thing: Hibernate works great with artificial keys. It can manage composite business keys but it's much more work. Ibatis and spring-jdbc are not sophisticated enough for this issue to matter for them.

If your developers are cautious and thorough, and if you can keep your approach simple (for instance, using session-per-request, not retaining any objects from one session to the next, and using artificial keys), then go with Hibernate. If you've decided you don't need the database abstraction that Hibernate provides, or you don't trust your developers with sharp tools, then go with Ibatis. Keep spring-jdbc in mind as a fall-back to do particular queries that need bare-metal jdbc tweaking.

By the way, Grails and GORM make Hibernate much easier to experiment with because there's so much less setup time, Grails starts you out with an in-memory database and you can get by without writing mapping files.