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 Mon, 07 Nov 2005 07:37:03 GMT
>> The fact that it currently translates the resultsets into an object model

>> As a matter of fact, it could be argued that /that/ part of iBatis is its
/weakness/.

That part? That's not a part...that's ALL iBATIS does. If you've
misunderstood that, then I'm sorry for our lack of clarity.

>> Look at some of the comments Gavin is making about /lack/ of
>> ORM functionality in iBatis because of this:

Gavin's right. We lack a lot of ORM features. Because we're not an ORM.

>> Woah, so iBatis is an ORM? Is that what we conclude here?

No, you are the only person suggesting that thus far. All I've said is: call
it that if you want. I can't seem to convince you otherwise. It seems that I
could only do so by supporting disconnected rowsets. We may indeed do that
in the future...but not for the reasons you're suggesting. For a good
description of the differences between ORMs (Metadata Mapper) and iBATIS
(Data Mapper) and Table Data Gateways (DataSets), see Martin Fowler's
Patterns of Enterprise Application Architecture.

>> If we go iBatis, the folks who want to use Hibernate will ask for
>> the "missing" Hibernate features in iBatis.

Your clients will never get Hibernate features without using Hibernate.
Disconnected rowset support in iBATIS won't change that. iBATIS and
Hibernate do not compete at the same level, no matter how much some people
would like them to. They are hardly even in the same problem space.

I see you've entered the feature request in JIRA. It is likely it will make
it into some future release.

Cheers,
Clinton


On 11/7/05, Abdullah Kauchali <abdullah.kauchali@isanusi.com> wrote:
>
> Clinton Begin wrote:
>
> > >> I think we very badly need support for disconnected "datasets" or
> > resultsets in iBatis.
> >
> > Datasets, rowsets, strongly typed or not are generally a horrible
> > design choice and shouldn't be used in any sort of system that
> > requires a maintainable object model that can exist with or without a
> > database.
>
>
> That is simply not true. Introducing datasets takes nothing away from
> the /real/ power of iBatis - the ability
> to construct and refer to (call) statements through generic parameter
> objects. The fact that it currently
> translates the resultsets into an object model (ORM style), IMO, is
> really not its strength. As a matter of fact,
> it could be argued that /that/ part of iBatis is its /weakness/.
> Because people begin to expect the whole
> ORM kitchen sink with it too. Look at some of the comments Gavin is
> making about /lack/ of ORM
> functionality in iBatis because of this:
>
>
> http://forum.hibernate.org/viewtopic.php?t=946112&view=next&sid=16a15cd9d22236aaded5c042ec758841
>
> "Does it support dirty checks". That is so totally irrelevant to iBatis.
>
> > ORMs are not bad for WHAT they intend to do. They are sometimes just
> > overcomplicated because of HOW they do it.
>
> Yes.
>
> > We should be working with rich object models, not with two dimensional
> > arrays of disorganized bits.
>
> "Rich object models" is the puzzle ORM's intend to solve. If iBatis is
> /all/ about that, then I'm afraid it
> is an ORM - and I fear Gavin is right when he says key functionality is
> missing with iBatis.
>
> The fact is, we are not intending to use iBatis in that way. We have
> successfully created models without
> rich object models that use simple beans and lists as disconnected
> datasets. And the concept works
> perfectly. But it is cumbersome because we don't have the full power of
> a cachedrowset or analogous.
>
> > >> A concept like strongly typed datasets from .NET will be a /dream/!
> >
> > Hey, did you know that Hibernate supports strongly typed, disconnected
> > data? Check it out.
>
> I will, thanks. :) But, I'd rather construct and organise my SQL/sp
> statements through iBatis. It's just
> so much better!
>
> > Call it what you want, ORM or whatever. iBATIS is iBATIS. It does
> > what it does. We're not trying to fit into any mold.
> > >> And the last thing I want to do is waste my time defending ORM for
> > iBatis' sake!
> >
> > If you have to defend it, there are two possibilities. 1) iBATIS is
> > the wrong choice for you're situation, or 2) you're talking to the
> > wrong people. Either way, we don't typically build features simply to
> > satisfy any debate.
>
>
> Woah, so iBatis is an ORM? Is that what we conclude here?
>
> Clinton, this is not just a debate for us. We have to make some hard
> choices soon. If we go iBatis, the folks
> who want to use Hibernate will ask for the "missing" Hibernate features
> in iBatis. If I am going to make a
> convincing case for my clients about the use of iBatis in a
> "disconnected dataset" scenario, I better make a
> compelling case that it supports the features easily.
>
> But I see, you are getting upset. :(
>
>
>
>
>

Mime
View raw message