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. :(
