There is an object relational mapper out there that is a hidden gem. Instead of creating a full domain model, its job is to map Java objects directly to SQL statements. This framework is called iBatis, and its goal is to implement 80% of the JDBC boilerplate code you would otherwise have to do yourself. In addition, it provides a simple mapping and API layer that lets developers quickly develop data access code. This article explains how iBatis can help you.
I use Springs JDBC templates quite a bit. I have looked at iBatis, but it looks like it accomplished the same goal and since I was already using Spring JDBC I just stuck with it.
Is there anyone out there using both, and can talk about the differences between the two and why iBatis is better?
Also doesn’t FireStormDAO have a product that will read your database and generate all your JDBC SQL statements for you. I don’t know if it manages resources for you like Spring and iBatis, but it seems more like them then Hibernate or Toplink for example.
Edited 2005-11-30 17:28
Spring provides iBatis support out of the box and the combination of the two is excellent. The main benefit that iBatis gives you is the ability to still have access to your SQL. This allows for performance improvements and developers with basic SQL skills can instantly be productive. iBatis stores the SQL in an external file, so it is not sprinkled throughout your java code. And of course, all of the mapping between your SQL and your java objects is in this same external file. Makes for a pretty clean separation…
-G
Anyone? Anyone?
Ibatis is not exactly an ORM tool. you are still depending on DB dependant SQL code. In ORM tools such as Hibernate, it is possible to make all your DB operations wthout writing a single line of SQL. But if you want you can use native SQL calls in hibernate too.
With hibernate changing your database is very easy. With Ibatis this might be painfull. Of course main reason for chosing Hibernate should not be db Portability but develper skills.
if your team is very strong in JDBC and SQL database skills, Ibatis might be a better choice. But if team is strong in Object oriented skills, Hibernate should be the way to go.
if there is already a legacy database, sometimes it would be hard to fit it to an object schema, then Hibernate would be difficult to use. Also Hibernate’s learning curve is steeper then iBatis in cases.
ibatis has small amount of dependencies. Hibernate has a lot(8 jars i think). it does not matter in server systems, but client side applictions is another story.
At the end, everything depends on your project requirements and team skills ..
I built a template driven data-access code generator (that generates 80% of the JDBC calls needed) a couple of years ago. More recently I’ve been using Toplink and Hibernate. Given how well the O/R tools are, I don’t even think in terms of SQL any more
mainly because learning curve is very big compared with plain jdbc, if you already know how to program using plain jdbc or some wrapper around it, that may speed up your development many times , advantages of those frameworks only are seen on big projects and after learning curve is finished
Hibernate has features iBatis just doesn’t have. It may not be as easy but still not as robust…and requires hand-coded sql.
people that used both alternatives like Spring/Hibrenate end up perfering iBatis, and a lot.
For small projects SQL can be bypassed, butnot for comerical development.
.V
…and ended up switching to (and eventually becoming a committer to) iBATIS.
In my experience, iBATIS was *WAY* easier to learn than Hibernate. It also worked much better with our existing (shared) database. We were working with around 800GB of data, and ~200 tables. Mapping all of that in Hibernate was just not an option.
We also found that the support for stored procedures, row handling, and dynamic SQL in iBATIS was far superior.
Another thing that iBATIS brings to the table is that it allows your DBA to optimize the SQL. Yes, you have to write SQL, but … seriously … how hard is a select statement? Or an insert, delete, or update?
IMO, HQL was every bit as wacky as SQL, but no one knew how to optimize it because it was (and is) only used by Hibernate users. Can you find me a DBA that knows HQL? Not very darn likely.
On a philosophical note, where is the value of an enterprise system – in the code or in the data? In many cases, the technology (i.e., the code) changes, but the data lives on. With that in mind, I’ll stick with SQL (i.e., native data access) until my database vendor tells me that they have something better.
Edited 2005-12-01 13:34
I would encourage anyone to also look at O/R Broker, which is somewhat similar to iBatis, but does not impose any restriction on the domain model design, such as the very anti-OO JavaBeans component model.
http://www.orbroker.org