Apologies in advance, this is likely going to be a long-winded message.  ;)

To give everyone a perspective from the "other side of the tracks", I
am a relatively new user of iBATIS, but I previously had well over a
year of solid Hibernate experience in production (with another year of
'tinkering' with Hibernate before that, dating back to Hibernate 1.2).
 I've also used Apache's Object Relational Bridge (OJB) in production,
and have 'toyed' with JDO, Apache Torque, Cayenne, Castor and even
pBeans.  ;)  Of course, I've done a *lot* of JDBC and some EJB entity
beans (but very little -- not a big fan of these ;)

While I've only been using iBATIS for about 3 months, I'd say the
situation for using iBATIS over Hibernate is much as Paul described,
but I'd like to possibly stress that it might be even more polarized
than he indicated.

As a part of the architecture team on my last project, we had the
'luxury' of dictating the data model as well as the choice of
object-relational mapping tools.  A previous iteration of the software
we were "refactoring" had tried a custom JDBC framework that was very
difficult to maintain, and scalability was always in question.  We
decided to accept an industry standard "universal data model" and
tried to make Hibernate "fit" with it, instead of letting Hibernate
"push" the objects into a relational data model (which is the easiest
way to use Hibernate).  For those of you not familiar with Hibernate,
I would not recommend trying to force Hibernate to work with a data
model.  There are certain Hibernate guidelines that you must fit
within (from a relational perspective) in order to not encounter
issues.  All in all, though, once you "tweaked and tuned" Hibernate
and the relational model to compensate, it turned out to be very nice
to work with.  The mapping was all done within the Java classes, using
XDoclet and generated mappings with an Ant task.  Afterwards, querying
for objects already mapped was a very, very trivial task -- and
inserts, updates and deletes were equally simple, especially with
large object hierachies.  Being able to say
".save(GreatGrandParentObject)" and have it save all GrandParents, all
Parents and all Children automatically (or updates or deletes without
worry what needed to be done where) was quite nice.

On to my current project we use iBATIS, since a large portion of the
SQL had been or is created by several developers with years of
experience in SQL against an "off the shelf" ERP data model (i.e. very
little control over).  In this case, iBATIS is lightning fast to use: 
copy the SQL statement directly from your favorite SQL query tool,
past into the SqlMap XML file, and write your mapping ResultMap, and
viola, you're up and running.  Unfortuantely, I've not had much
experience with the "push" part of iBATIS (updates, inserts, delets),
so it's difficult to speak here, but I would expect the same 'ease of
use'.  I recently made the statement to a co-worker that I'll probably
never use straight JDBC again because of iBATIS.

Finally, regarding performance turning: I'd say that this depends on
your experience with each product, and SQL in general.  There are a
number of "tricks" in Hibernate (with lazy loading, proxies and
caching) that can be used to "tune" a particular situation.  The same
would apply to iBATIS, as long as you were pretty good with SQL and DB
design (indexes, eliminating LIKEs and other things that might force
full table scans, etc.).

So in summary, Hibernate is great when you control the data model, and
you let Hibernate do most of the work in the persisting of objects. 
Trying to add Hibernate to an existing data model is possible, just
usually not trivial (unless your models trivial).  On the flip side,
it's least likely to please a DBA since the relational scheme could
look 'odd' in situations, and the SQL is more difficult to tune.  But
once it's setup and tuned, you'd begin to see your biggest
productivity gains.

On the other hand, it feels as if iBATIS can adapt to any situation,
but of course this is (in my opinion) highly dependent on the SQL
skills and experience within your organization.  It's just as easy to
write a 10 table JOIN with 3 sub SELECTS and 5 LIKE clauses against a
few million records to see problems.  ;)  Likewise, if you have a good
DBA or good SQL developers, this situation is MUCH, much easier to

I hope someone finds this information helpful. 

On Sat, 26 Feb 2005 22:47:30 -0700, Larry Meadors
> On a related note: I am in the process of refactoring an application
> where I work that used Hibernate. One of the screens that was timing
> out after over 10 minutes is now coming up in under one minute.
> In my experience, the performance of Hibernate (especially when
> dealing with large datasets) is VERY overrated.
> That said, if you will be working with large data sets, and
> performance is a criteria, my suggestion would be iBATIS.
> Larry
> On Sat, 26 Feb 2005 20:21:38 -0700, Clinton Begin
> <[EMAIL PROTECTED]> wrote:
> > Well said Paul.
> >
> > Clinton
> >
> >
> > On Sat, 26 Feb 2005 21:20:19 -0500, Paul Barry <[EMAIL PROTECTED]> wrote:
> > > I don't know of a site with a detailed comparision, and if you find one,
> > > let me know.  But I can tell you this difference boils down to this;
> > > iBATIS maps Java Objects to the results of SQL Queries, whereas
> > > Hibernate maps Java Objects directly to database tables, traditional
> > > Object-Relational Mapping.  The benefits of Hibernate are that it
> > > automatically generates all the SQL for your and the cache invalidation
> > > can be more fine grained.  iBATIS is more flexible especially if you are
> > > a strong SQL query writer.  You have control over exactly how the SQL
> > > queries are written.
> > >
> > > When determining which framework to use, I think one thing to remember
> > > is that there is an optimal relational model to support every object
> > > model.  There is not an optimal object model to represent every
> > > relational model.  Use hibernate if you have mostly standard
> > > queries(CRUD, Find by Criteria, etc.) and if you are designing your
> > > object model first, then a relational model to support the object model.
> > >   If you are working with a legacy system or a schema designed by a DBA,
> > > iBATIS often makes a better choice.  If you try to shoehorn hibernate
> > > into a relational model created by a DBA who could care less about
> > > objects and thinks in terms of tables, columns, relationships and record
> > > sets, then you will get along better with your DBA if you use iBATIS,
> > > especially if the model is complex and may entail queries with outer
> > > joins and nested subqueries.  You can tell them "All of the SQL
> > > statements used by my application are stored in these XML files outside
> > > of my Java code, so you can easily review them".  DBAs like that.  Of
> > > course, you might be lucky enough to work with a DBA that is familar
> > > with OO design and ORM tools like hibernate, in which case hibernate
> > > might make a better choice.
> > >
> > > Bottom line, in my experience, compared to Hibernate, iBATIS is more
> > > flexible, has a shorter learning curve, but can take more time to
> > > develop and maintain, since you have to write all your queries and if
> > > your object model changes you have to go through all your queries and
> > > make sure to make all the necessary changes to reflect the changes in
> > > your object model.  I must admint though that I am biased because I have
> > > more experience with iBATIS.  As I gain more experience with Hibernate,
> > > I could be singing a different tune.
> > >
> > >
> > > Tim Christopher wrote:
> > > > Hi,
> > > >
> > > > Can anyone point me in the right direction of a site that compares
> > > > iBATIS to similar products, ie. Hibernate.
> > > >
> > > > Cheers,
> > > >
> > > > Tim Christopher
> > > >
> > > > Ps. Is it possible to specifiy a flush interval in a unit other than
> > > > hours?  Also is there an upper limit for the time?
> > >
> >

Reply via email to