ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <clinton.be...@gmail.com>
Subject Re: iBatis and ORM's
Date Sat, 05 Nov 2005 14:51:03 GMT
This is really good discussion. I hope you guys help Kim with the FAQ, and
post your feature requests to JIRA (I think "use iBATIS as a spreadsheet" is
already in there). ;-)

Cheers,
Clinton

On 11/5/05, Alan Chandler <alan@chandlerfamily.org.uk> wrote:
>
> 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?
>
> Well
>
> 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
> http://www.chandlerfamily.org.uk
> Open Source. It's the difference between trust and antitrust.
>

Mime
View raw message