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.
