ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Chandler <a...@chandlerfamily.org.uk>
Subject Re: iBatis and ORM's
Date Sat, 05 Nov 2005 11:43:04 GMT
On Saturday 05 Nov 2005 09:38, Abdullah Kauchali wrote:
> Alan Chandler wrote:
> >http://home.chandlerfamily.org.uk/archive/26/ibatis-v-hiberbate)
> <Quote>
> In simple terms, Hibernate maps Java Objects to database tables.
> iBatis maps Java Objects to SQL statements.
> </Quote>
> Hang on a sec here, don't we also map Java Classes to database tables
> with iBatis?  A User class
> in my design maps to a User table in the database.   Isn't this exactly
> how the iBatis docs tell us
> we should map our result beans?


a) I was simplifying, but yes we map to beans not objects - but I have a 
message that I want to get across
b) We do NOT map directly to tables, only to the results of a SQL statement 
(which - as you say - might be a table).  But the crux of my arguement is 
that although for simple CRUD you might have that simple mapping, any real 
application is more complex than that.

> Even though we have the ability to get results like COUNT, AVERAGE etc
> from separate statements
> in iBatis, 90% of our usage will be based on the Class-to-Table mapping
> mentality - exactly the
> starting point of an ORM tool.

I disagree if you design your database with proper normalisation.  In my 
recent family tree application of the 12 SELECT statements only 2 mapped 
directly to the table and 2 others half did (I added a dynamic where clause 
to limit the search via a filter).

> So, given that situation, we are left with the challenges inherent in
> the Class-to-Table paradigm.  (IMO, the
> remainder of the ORM conundrum!)  :-)  A challenge that arises when
> departing from the concept of
> handling data as SETS not objects!

As above, I think your premise to this bit is false
Alan Chandler
Open Source. It's the difference between trust and antitrust.

View raw message