http://www.osnews.com/story/12829/Tired_of_Hand_Coding_JDBC_iBatis_Can_Help Exploring the Future of Computing en-us Copyright 2001-2013, David Adams adam+nospam@osnews.com Sun, 19 May 2013 01:39:48 GMT http://www.osnews.com/images/osnews.gif http://www.osnews.com http://www.osnews.com/thread?67199 http://www.osnews.com/thread?67199 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 Wed, 30 Nov 2005 17:26:00 GMT donotreply@osnews.com (Matt Giacomini) Comments http://www.osnews.com/thread?67211 http://www.osnews.com/thread?67211 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 Wed, 30 Nov 2005 17:48:00 GMT donotreply@osnews.com (gmlongo) Comments http://www.osnews.com/thread?67227 http://www.osnews.com/thread?67227 Anyone? Anyone? Wed, 30 Nov 2005 18:11:00 GMT donotreply@osnews.com (Anonymous) Comments http://www.osnews.com/thread?67262 http://www.osnews.com/thread?67262 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 .. Wed, 30 Nov 2005 19:03:00 GMT donotreply@osnews.com (ahmetaa) Comments http://www.osnews.com/thread?67314 http://www.osnews.com/thread?67314 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 Wed, 30 Nov 2005 21:01:00 GMT donotreply@osnews.com (Anonymous) Comments http://www.osnews.com/thread?67317 http://www.osnews.com/thread?67317 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 Wed, 30 Nov 2005 21:03:00 GMT donotreply@osnews.com (Anonymous) Comments http://www.osnews.com/thread?67371 http://www.osnews.com/thread?67371 Hibernate has features iBatis just doesn't have. It may not be as easy but still not as robust...and requires hand-coded sql. Wed, 30 Nov 2005 23:24:00 GMT donotreply@osnews.com (Anonymous) Comments http://www.osnews.com/thread?67547 http://www.osnews.com/thread?67547 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 Thu, 01 Dec 2005 11:13:00 GMT donotreply@osnews.com (Anonymous) Comments http://www.osnews.com/thread?67567 http://www.osnews.com/thread?67567 ...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 Thu, 01 Dec 2005 13:32:00 GMT donotreply@osnews.com (lmeadors) Comments http://www.osnews.com/thread?68017 http://www.osnews.com/thread?68017 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 Fri, 02 Dec 2005 16:50:00 GMT donotreply@osnews.com (trefork) Comments