Flawed JDO Points the Way to the "Objectbase"
Subject:   JDO can give us more than just JavaBean functionality
Date:   2002-04-26 14:31:13
From:   dion
Response to: JDO can give us more than just JavaBean functionality

Caching can be problematic

That is definately true, however, it can be a saviour. How often is the DB the bottleneck on large enterprise projects? I have been on many, where distributed caches have saved the day, giving fantastic performance, and allowing many more clients. Many web sites are heavy on reads. On TheServerSide.Com we make use of that fact with a read only cache of entity data, so we rarely even GO to the database (that is why the site is relatively fast!)

There is a LOT more to caching that caching db connections, which can be done in both JDO and JDBC of course. Ideally I don't want to even talk to a db unless I have too.

Tools don't really push data mapping out of code, ...

IMO, This abstraction can be a good thing. There are times where I just want to write my object, happen to make it persistent, and don't want to worry about the way the table looks. This allows me to use simple SQL for cheasy databases, but use Stored Procs on others, and to be able to change that without changing the code!

... you use JDO with a relational database, your object model exists only in your executable program, not in the persistence layer

How is this different between the two?
In general there are a couple of choices:

1. Store an actual object in a database
- tied to the language that the object is in
- hard to access state within the db
2. Store state of object in a database and have something map between the class and the db itself
- now anyone can query the state

JDO puts behaviour in the objects, and the state are mapped. This IS OO right? We can think of things in JDO as "I want this object persistent" and make it happen. When we need an object we get back the object with its state... and behind the scenes the data is managed for us by the PersistenceManager

I don't think JDO > JDBC, it is just another technology that can be used. Everything has pro's and con's, and business situations dictate a fair amount (e.g. "I can do everything in Java", "I know that I will be using Oracle", etc).
SQL is great, but in my experience, although a lot is "standard" there are always quirks that each vendor puts in there (like anything else), so it isn't easy to jump from one db to another. I also don't think that people DO jump between databases a lot. The best part of standards like JDBC are because I can *learn* one API, and when I move to another project that does use another db then I know the API to talk to it... and now I just need to learn the quirks (unless I just use a subset of things of course). It would be nice if sequences/identities/etc would be standardized :)

Cheers, and good article / book.