ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Medium <contactm...@gmail.com>
Subject Re: iBatis and ORM's
Date Sun, 06 Nov 2005 11:55:47 GMT


Hmmm...sounds like a pyramid scam opportunity. Now all you have to do is 
convince them to pay everyone on the list above them 1 dollar.

Except they get to use ibatis which should definitely get them their 
money back sooner or later.

Clinton Begin wrote:

>
> But if those two people convert two people each.....exponential growth!
>
> On 11/4/05, *Kim Goings* < kim.goings@levelfivesolutions.com 
> <mailto: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
>     <mailto: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
>     <mailto: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