>> 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.
ORMs are not bad for WHAT they intend to do. They are sometimes just overcomplicated because of HOW they do it. We should be working with rich object models, not with two dimensional arrays of disorganized bits.
>> 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.
>> IMO, the current way iBatis does things makes it more of an ORM than it does a "collection based" data
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.
Cheers,
Clinton
On 11/6/05, Abdullah Kauchali <[EMAIL PROTECTED]> wrote:
Clinton Begin wrote:
> This is really good discussion. I hope you guys help Kim with the
> FAQ, and post your feature requests to JIRA (I think "use iBATIS as a
> spreadsheet" is already in there). ;-)
If you mean my JIRA entry, then I agree. But, hey, you started the
"iBatis is a spreadsheet" analogy! ;-)
Anyways, IMHO, I think we very badly need support for disconnected
"datasets" or resultsets in iBatis.
A concept like strongly typed datasets from .NET will be a /dream/!
IMO, the current way iBatis does things makes it more of an ORM than it
does a "collection based" data
abstraction layer. :-) And the last thing I want to do is waste my
time defending ORM for iBatis' sake!
