continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trygve Laugstøl <tryg...@apache.org>
Subject Re: [discuss] iBatis, JPA and Java 5.0
Date Tue, 09 Jan 2007 08:09:36 GMT
Carlos Sanchez wrote:
> On 1/2/07, Rahul Thakur <rahul.thakur.xdev@gmail.com> wrote:
>> ----- Original Message -----
>> From: "Brett Porter" <brett@apache.org>
>> 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

Mime
View raw message