Demian L. Neidetcher| initial impressions of iBatis

At the new gig we're in the sweet position to do greenfield work. We're architecting, picking technology and of course implementing the solution. I knee-jerk assumed we would use Hibernate. Hibernate is the persistence framework you reach for when you're doing new development. But my CEO mentioned iBatis, so I thought I'd give it a look.

The Dice test:

Hibernate: 1564
iBatis: 85

So, yeah, there are substantially more Hibernate jobs than iBatis jobs at least on Dice. I used Hibernate at a previous job. It's great, does lots for you. However, anecdotally I can say that some strangeness can happen. When Hibernate does so much for you it can lull you into a false sense of security.

iBatis takes a different approach to persistence iBatis has you coding SQL in an XML file. The configuration is amazingly simple. It doesn't try to hide the fact that there's a database underneath there. It does have some facilities for manually wiring up objects and their associated collections. Instead of an ORM (object to relational mapper) I think it's a straight object to table mapper.

Should you use Hibernate or iBatis?

If you don't want to mess with SQL stick to Hibernate.
If performance might be an issue then use iBatis.
If you want to use tooling stick with Hibernate.
If swapping out the database is a possibility use Hibernate.
If you're comfortable with SQL and still want to use it, use iBatis.
If you're interested in simple solutions, use iBatis.
If you think you should never have to step out of the OO mindset, use Hibernate.
If you are chiefly concerned with your marketability, Hibernate is for you.

Going back to our specific situation. We're a 100% MySQL shop, we all (both) are very comfortable with SQL and we're in a situation where routing calls quickly is important (like 911). In our situation I think iBatis might be a good choice.

In my previous life, I had control of the entire application stack (JSP to SQL and all points in between). When you are in that much control you have the opportunity to do some interesting tweaks. You know a page would make 5 hits to the persistence layer, if you control the persistence then you can create 1 API call that does the join in 1 SQL query.

It seems that with Hibernate, if you are truly OO you can end up bringing over too much of the object tree. Sure you can tweak this in Hibernate but it's easy to gloss over. The alternative is having the persistence layer user do the circuitous treasure hunt anti-pattern. I think iBatis is going to let me get into some custom queries that let me traverse the schema in one query in the interest of performance and convenience.

Frankly, another reason I want to go with iBatis is because I'm getting deep into the database after a long time away. We're coming up with a great schema. A good schema is like a beautiful machine, giving you the data you need and ensuring that your data remains correct. Given that, I look forward to getting my hands dirty in the SQL again.

Performance isn't the absolute reason to make a technology decision but the numbers are interesting.
Here's an article that compares performance on various persistence frameworks.

Speaking of reasons you shouldn't consider but are interesting to note, Bill Dudney wrote a caution about investing your time in Hibernate.

Okay, with all that said. Hibernate has so much momentum that it's hard to go wrong by choosing it. Like with Googles recent contribution of shards to the Hibernate project. With that kind of focus, Hibernate will continue to be the most popular persistence framework.