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 00:48:50 GMT
But if those two people convert two people each.....exponential growth!

On 11/4/05, Kim Goings <kim.goings@levelfivesolutions.com> wrote:
>
> I will try. I've only been able to convert 2 people so far and would
> love to reach more. :)
>
> Kim
>
> On Nov 4, 2005, at 5:49 PM, Clinton Begin wrote:
>
> >
> > Sorry everyone. I didn't mean to sound like I don't care about such
> > comparisons.
> >
> > I think it is old for me, and I'm able to look at situation
> > objectively and decide whether Hibernate or iBATIS (or neither) is the
> > best choice. To me, it seems obvious.
> >
> > Perhaps this is a VERY long overdue FAQ that we need to add. Anyone
> > care to start it and begin collecting these thoughts?
> >
> > I would, but apparently I'm too jaded. ;-)
> >
> > Cheers,
> > Clinton
> >
> > On 11/4/05, Kim Goings <kim.goings@levelfivesolutions.com> wrote:
> >> been around it for so long.:)I think it's still valid.I've
> >> started to become quite the iBatis evangelist and when people ask why
> >> I
> >> think it is better or how it is different than Hibernate, the points
> >> you (and others) have made here are what I need to back me up.
> >>
> >> Like it or not, when people are deciding what to use on a project,
> >> it's
> >> not uncommon for iBatis and Hibernate to be the top two contenders.
> >> Maybe that's a growing trend stemming from painful Hibernate
> >> experiences.I think in many cases, people have realized they don't
> >> really need an ORM, but are fearful of pulling away because Hibernate
> >> is the "hip" way to go these days.
> >>
> >> They are different things and, as always, the best choice really does
> >> depend on the project.But for the most part, I think the decision
> >> often lies in the answer to "Are you comfortable with SQL?"or "Do
> >> you
> >> have a DBA?"(who presumably wants more control over what your app
> >> does to the db than Hibernate allows).
> >>
> >> Anyway....I love iBatis and would be hard-pressed to find any
> >> situation
> >> where it wasn't the best, or at least sufficient, choice.
> >>
> >> Kim
> >>
> >>
> >> On Nov 4, 2005, at 4:55 PM, Clinton Begin wrote:
> >>
> >> >
> >> >Try this with Hibernate:
> >> >
> >> >int i = (Integer) client.queryForObject ("countUsersInGroup",
> >> > "MyGroup");
> >> >
> >> ><select id="countUsersInGroup" resultClass="int"
> >> > parameterClass="string">
> >> > SELECT Count(1) FROM Users WHERE GroupName = #groupName#
> >> ></select>
> >> >
> >> > In asking yourself why this isn't possible in Hibernate, you'll
> >> answer
> >> > your first question.
> >> >
> >> >To answer the third question, try this with Hibernate:
> >> >
> >> >client.delete("deleteUsersInGroup", "MyGroup");
> >> >
> >> ><delete id="deleteUsersInGroup" parameterClass="string">
> >> > DELETE FROM Users WHERE GroupName = #groupName#
> >> ></delete>
> >> >
> >> >In asking yourself why this isn't possible, you'll answer part of
> >> the
> >> > third question.
> >> >
> >> >The rest of the answer to the third question is this: Generally
> >> > systems involve many more SELECT statements than INSERT, UPDATE and
> >> > DELETE combined. Usually all of the value in a relational database
> >> > system is realized from the SELECT statements. Nobody makes money on
> >> > INSERT, UPDATE and DELETE. ORM solves INSERT, UPDATE and DELETE very
> >> > well (as long as you're not talking batch updates and deletes). But
> >> > ORMs generally do very little for SELECT, and in fact, ORMs often
> >> > complicate SELECT. Having experienced this myself, I'll say that
> >> > beyond INSERT, UPDATE by PK, DELETE by PK and SELECT by PK....ORMs
> >> > don't generally help much.
> >> >
> >> >What ORMs do very well though is manage the relationships between
> >> > objects and how the impact a change to one object should (or should
> >> > not) imact related objects. ORMs also tend allow for much more
> >> > effective caching of objects (thanks to OID).
> >> >
> >> >But anyway, this is an old discussion that's become way to old. The
> >> > real answer to your question is another question: why are you
> >> > comparing an ORM to iBATIS? It's like comparing a Spreadsheet tool
> >> to
> >> > a Word Processor.
> >> >
> >> >Cheers,
> >> >Clinton
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On 11/4/05, Abdullah Kauchali <abdullah.kauchali@isanusi.com> wrote:
> >> >>
> >> >> Clinton Begin wrote:
> >> >>
> >> >> > ORM
> >> >> >
> >> >> > 1) Maps classes to tables, and columns to fields.
> >> >>
> >> >> Don't we do that with iBatis too? Are we saying that mapping
> >> classes
> >> >> to tables, and columns to
> >> >> fields is generally a bad idea?
> >> >>
> >> >> > 2) Must support Object Identity
> >> >>
> >> >> Yes, of course.Excellent point, thanks!
> >> >>
> >> >> > 3) Generates SQL
> >> >>
> >> >> Agreed.But tools like Hibernate allow for adhoc queries.Could the
> >> >> fact that this "escape hatch"
> >> >> (to allow for ad hoc or "hand written" queries) be taken as an
> >> >> argument
> >> >> that such tools are in fact
> >> >> exactly like iBatis but with /more/ features?(Did I phrase that
> >> >> right?)I guess, what I really want to
> >> >> ask is:what is the trade-off or compromise in the design when
> >> >> Hibernate users begin to use the
> >> >> ad hoc query facilty?(There has to be a cost!:-))
> >> >>
> >> >> >
> >> >>> SQL Mapping
> >> >> >
> >> >> > 1) Maps objects (not necessarily a custom type, or even the same
> >> >> type)
> >> >> > to statements
> >> >>
> >> >> Clinton, I am trying to understand this carefully.Don't you mean
> >> >> "map
> >> >> objects to rows of a resultset
> >> >> created from a statement?"
> >> >>
> >> >> If so, how is this any different from what Hibernate does with the
> >> ad
> >> >> hoc facility.
> >> >>
> >> >> > 2) Generally does not support object identity (would be hard to
> >> do)
> >> >>
> >> >> Ok, great.Excellent point.
> >> >>
> >> >> > 3) Allows complete hand coding of real SQL, with full support
for
> >> >> > nearly all RDBMS features
> >> >>
> >> >> Fantastic!
> >> >>
> >> >> Regards,
> >> >>
> >> >> Abdullah
> >> >>
> >>
>
>

Mime
View raw message