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.
