Re: JDO comparisons
From: Marc Prud'hommeaux <marc_at_solarmetric.com>
Date: Fri, 15 Feb 2002 02:38:26 GMT
Message-ID: <Bw_a8.2500$5z.1386782_at_paloalto-snr2.gtei.net>
Date: Fri, 15 Feb 2002 02:38:26 GMT
Message-ID: <Bw_a8.2500$5z.1386782_at_paloalto-snr2.gtei.net>
In comp.databases.object Angus Monro <ajmonro_at_ingennia.com.au> wrote:
> Specifically, we are considering three possibilities:
> (1) continue doing what we're already doing i.e. writing our own
> relational db access code via JDBC
JDO is gaining vendor support, and will probably become the standard in object-oriented data access. I would strongly recommend going with a JDO implementation over hand-rolling it, for the following reasons:
- one less segment of your code to have to maintain
- JDO implementations will only get better over time
- JDO is designed to be vendor-independant, so you can always swap out implementations should a vendor come out with a better version than you are using. While "vendor independance" is a bit of a myth these days (just try swapping EJB Containers or JDBC drivers, and see how much of your code continues to work), JDO will hopefully usher in a new era where programmers can utilize a standard data access service and be confident that it will work in any environment.
> (2) use Solarmetrics' Kodo JDO on top of an RDB
> (3) use Prism Technologies' "Open Fusion" on top of an RDB.
Well, I am biased, but I would say: go with Kodo! You can download a free evaluation at http://www.solarmetric.com.
-- Marc Prud'hommeaux marc_at_solarmetric.com SolarMetric Inc. http://www.solarmetric.com Kodo Java Data Objects Full featured JDO: eliminate the SQL from your codeReceived on Fri Feb 15 2002 - 03:38:26 CET