ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Lamey" <cla...@localmatters.com>
Subject RE: New to iBatis
Date Mon, 18 Jun 2007 05:09:00 GMT

I've been using iBATIS as the db interface for APIs that are used by many different kinds
of clients for almost two years now.

When I get a request for a new piece of functionality, I first try to implement it using only
Java and the Abator generated classes.  A good chunk of the "no brainer" work can be handled
this way without writing any new SQL or touching the XML.

If the functionality does require new SQL, I generally try to make the SQL return something
that can be used by an Abator generated result map or a simple grouping result map using the
Abator generated classes. 

For queries with results that don't map well to the Abator classes, a good chunk end up being
scalar values (string or int) or to lesser degree a Map.  If that doesn't work then I'll go
to a RowHandler with a Map result class.  These RowHandler queries make up a small percentage
of my iBATIS SQL but generally are the most complicated and performance aware SQL I have.
 I should probably write more complicated result maps in the sql map XML, but I find it much
easier to handle a Map in Java than group things together in XML.

I guess what I'm saying is that if your data model is static, your model objects will be static
too and you can reuse them in different sql maps.

My experience with Hibernate is that it's fast and easy to get going out of the box and much
more OO friendly, but you spend all your time reverse engineering Hibernate to figure out
what its doing when against the RDBMS.  If you don't have high performance SQL requirements
and you have a small dataset, then Hibernate might be all you need.

For me, iBATIS takes a little more up front time because you don't automatically get joins
or CRUD (although Abator goes a long way with the CRUD handling).  But you have complete control
over what gets run when, which makes all the difference for me.  I recently wrote an app in
a few weeks that had to deal with 30M+ row tables and knowing exactly what is running when
is required for that kind of thing.

But then, in the impedance mismatch war, I'm OK with favoring the relational model because
I know how to make it scale and I know it'll be around in 10 years when we're all writing
Ruby clients;)


-----Original Message-----
From: vinays84 [mailto:vinays84@hotmail.com]
Sent: Sun 6/17/2007 3:15 PM
To: user-java@ibatis.apache.org
Subject: RE: New to iBatis

Thanks for all the replies. I'd like to quickly compare using iBatis vs.
Hibernate. I'm not an expert on either, so please correct any false
assumptions I make:

With Hibernate, the entire data model is mapped out for the application,
which can initially take a while and have a lot of configuration, but once
complete, will allow the developer to access the update the data model as
the application develops with any specific queries that they see fit,
without adding any extra POJOS or configuration code.

iBatis, on the other hand, is much simpler to set up, but configuration and
java code (POJOS and DAOS) will have to be added as more queries are added
to the application because each result class will have to be specifically
designed for the individual query.

Please edit/add anything that you think so I may get a proper understanding
of the differences between the two frameworks.

View this message in context: http://www.nabble.com/New-to-iBatis-tf3922862.html#a11167014
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.

View raw message