ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kim Goings <kim.goi...@levelfivesolutions.com>
Subject Re: iBatis and ORM's
Date Fri, 04 Nov 2005 23:25:17 GMT
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 <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