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
