iBatis in the Wild (vs. Hibernate)
Recently I’ve begun to use iBatis on several of my projects. Believe it or not, the large financial firm I work at actually recommends iBatis. However, I usually ignore their recommendations, but this time they are right on the money.
For these projects, I looked at both iBatis and Hibernate. Here are a few requirements I was looking for:
- Easy of Use and Standardization (as opposed to what one usually looks for, complexity and colvolutions). I was really looking for a simple and organized framework that encapsulated the database interaction. A framework that everyone could adhere to and I would no longer have to worry on the individual developer’s expertise or skill. I can’t tell you how many times I’ve see people create a project specific database connection manager.
- Separation of the SQL from the Java Code. This again comes back to preventing inexperienced developers (regardless of the number of years they have been working) putting what they call dynamic SQL directly into the Java code. I personally call this a dynamic mess! Having your SQL statement written as a bunch of variables with if statements, finally concatenated at the end is confusing and not maintainable. When I ask for the SQL statements, I’ve often heard that it is difficult to get and/or they need to search the logs. And what really gets me is that a change to the SQL query requires a recompile and release of the whole WAR/EAR file (if using an Application Server).
- Simple Serverside Caching. Instead of having to build you own caching system for static or often used data, we want to have the ability to say turn on caching for this query, but not this one.
If you’re familiar with iBatis and Hibernate, you’ll immediately see that both meet the criteria we layed out. However, there is a big difference between the philosophy of iBatis and Hibernate:
Hibernate: “A powerful, high performance object/relational persistence and query service. Hibernate Core for Java generates SQL for you….”
iBatis: “Couples objects with stored procedures or SQL statements using a XML descriptor. Simplicity is the biggest advantage of the iBATIS Data Mapper over object relational mapping tools.”
Essentialy, Hibernate is a true Object Relational Mapping tool. It maps Java objects to databases tables and will generate the SQL code for you. Hibernate is quite powerful and has a wealth of features (its own query language, the ability to query across multiple databases, etc.) It certainly meets all the above requirements plus more.
iBatis on the other hand is much more simplistic and maps Java objects to SQL instead of database tables. It won’t generate SQL for you and has a limited feature set compared to Hibernate. However, it does meet all the above requirements as well as Hibernate.
Now the question is which to choose. One might lean towards Hibernate, but there is a key factor that makes Hibernate (as an OR Mapper) virtually unusable in large organizations: Hibernate puts the development, maintainiance, and responsibility of the SQL coding forever in the hands of the Java development team. In most large organization a DB development group exists (sometimes incorrectly called the DBAs). This group should be the all encompassing database experts. They know the data, structure, and performance. They are the ones who can best write and maintain the queries to their system. Hibernate in its pure form takes this responsibility away from the experts. It has the Java development team saying, “oh, I know you’re the best to do this work, but don’t worry we’ll take it on forever more, but thanks for asking.” In a smaller organization the Java and DB developer might be one in the same, so Hibernate might be a perfect solution. In a larger organization there are multiple groups with their own specialties. I believe that allowing the other groups to contribute their full potential to the product is essential for success. (Hibernate can output the actual SQL generated, but try giving that to the DB group and see just how far you get…or asking for help with HQL [Hibernate Query Language].)
On the otherhand, iBatis is quite simple and allows you to separate you SQL (or Stored Procedure call) into an XML file. A few more lines and caching is enabled. That’s it! Your SQL remains in tact and you can allow the DB group to maintain the queries. While not the swiss arm knife of Hibernate, it get the job done quickly and easily. It is a simple framework that standardize the database interactions and keeps the SQL pure and ready to be maintained by the database experts.
One final point is that one might say, “well Hibernate can call Stored Procedures just like iBatis.” That is true, but it you’re going to just called stored procedures, one can only assume your main goal is to separate out the calls from the Java code into XML. If so, why add the complexity of Hibernate (and poweryou’re not using) instead of going with the simplicity fo iBatis?
Overall, iBatis has been exactly what we needed! Simple, standardized, fast and easy to maintain. And the caching is so wonderfully easy to use it alone would make me recommend iBatis.
In another post I’ll discuss my experience with Spring DAO and iBatis.