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 14:27:04 GMT
>> I am simply asking for clarification.

And now you have it.


On 11/7/05, Abdullah Kauchali <abdullah.kauchali@isanusi.com> wrote:
> Clinton Begin wrote:
> > >> 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.
> As far as I know (please correct my ignorance), iBatis does the following:
> 1. It does a good job of hiding tedious JDBC stuff (transaction stuff
> included) through a "best practices"
> approach;
> 2. It does a fantastic job of dynamically constructing SQL/sp
> statements (complete with iterations,
> string replacements etc);
> 3. It does a good of "organising" your SQL statements /outside/ your
> application;
> 4. It does a good job of mapping query results to an object model; :)
> 5. It /also/ returns simple collection objects (very much like datasets
> but without the built-in
> expression support, metadata or navigation support you'd normally
> associate with datasets.);
> 6. It does a brilliant job of caching /results/ from SQL statements or
> stored procedures;
> (There are more I'm sure.)
> Now, depending on the circumstances, a user of iBatis may or may not
> find any one or more of the above
> features useful. In some cases, some of the features are totally
> useless. In /my/ situation, feature number 4. is
> a total waste of time! Why? Because we're not interested in the ORM
> features of iBatis. Instead, we are
> interested in the "collection" model of iBatis - a functionality
> currently afforded by iBatis when we avoid
> doing the "rich object model" stuff (feature 4.).
> > >> 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.
> That, IMHO, is a wrong reason to say "we are not an ORM". A correct
> conclusion from that is that "we
> are a *bad* ORM". It just gives more ammo to the Hibernate folks.
> Needlessly.
> > No, you are the only person suggesting that thus far.
> I am simply asking for clarification. I began this thread by saying
> "iBatis is /not/ an ORM." I wanted to
> understand why you say that too. And if you believe it, give some good
> reasons, because I need to use
> them for iBatis' sake in our project.
> > All I've said is: call it that if you want.
> I certainly don't want to call iBatis an ORM because I believe it offers
> a paradigmatically alternative
> solution strategy to ORMs. I believe it is not an ORM - not because it
> lacks key features of an ORM - but
> because it offers a "dataset" based solution too.
> > I can't seem to convince you otherwise.
> I doubt you will convince anyone by saying that iBatis is not an ORM
> because it has some ORM stuff but
> it lacks some key features of an ORM. That simply is not going to be
> fruitful. It's like saying a half-baked
> cake is not a cake. It's simply a /bad/ cake.
> > It seems that I could only do so by supporting disconnected rowsets.
> iBatis currently supports disconnected rowsets. Yes. But not the
> standard ones. Yes, I would certainly be
> happy if I could have iBatis return a rowset instead of me constructing
> one by the row handler logic. I would
> really appreciate the effort towards that. Without a doubt. (I wonder
> how many others would too?)
> > 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.
> I will thanks.
> > I see you've entered the feature request in JIRA. It is likely it
> > will make it into some future release.
> Yup. :) I am really hoping you guys would find some time to look into
> it. Really. :)
> BTW, I mean offense or disrespect for the valuable time and effort all
> you guys put into iBatis. I love iBatis.
> I would like to continue using it and trust that my comments here are
> only received as a way to improve on
> it!
> I certainly hope so.

View raw message