Carlos Sanchez wrote:
On 1/2/07, Rahul Thakur <[EMAIL PROTECTED]> wrote:
----- Original Message -----
From: "Brett Porter" <[EMAIL PROTECTED]>
To: <continuum-dev@maven.apache.org>
Sent: Wednesday, January 03, 2007 4:59 PM
Subject: Re: [discuss] iBatis, JPA and Java 5.0
> I've been thinking stay with JDO for now, look at JPA in the long
> term.
>
> I haven't used iBatis, and would be happy to hear some practical
> experience from people who have. I tend to think of it as "a more
> productive JDBC", as opposed to the different programming model of
> JDO/Hibernate/JPA.
>
I haven't used it either, but that thread got me thinking about what
would drive the choice of a persistence solution if we were rethinking
jpox.
I did use it and yes, it's a "more productive" JDBC. If you need to do
low level stuff then go for ibatis, but I wouldn't do it for Continuum
unless really needed, it's going to be pretty verbose.
I agree with this, iBatis makes your code very verbose and it is not
nearly as elegant as it coult be. I've been trying out out iBatis for a
while not, and it's not really that much easier to program with than
JDO, and if you have a rich object model like Continuum has it really is
a pain to make sure you SELECT the entire model and UPDATE when storing.
Doing dirty checking and fancy stuff like that that the OODB/ORM-style
tools can do you can just forget about doing.
I don't thing it's a good idea to have several implementations of the
data store (JDO, ibatis, JPA,...), there's gonna be a lot of
refactoring work and one will be the default while the others won't
get a good level of stability not being widely used.
I wholeheartedly agree that having many implementations of the store is
not a good idea as other has said in this thread before, the different
models are too different and there is no good reason to have many
implementations at the same time. Branching and trying out a replacement
is one thing, but there should not be multiple implementations at once.
[snip]
--
Trygve
