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 <[EMAIL PROTECTED]> wrote:
Clinton - This discussion is probably far too old for you since you've
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 <[EMAIL PROTECTED]> 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
>>
