Hear us Roar
Article:
 |
|
Flawed Understanding of JDO Leads to FUD
|
| Subject: |
|
JDO makes DB dependent on Java |
| Date: |
|
2002-06-02 00:33:30 |
| From: |
|
tomdavies
|
Response to: JDO makes DB dependent on Java
|
|
If there is a performance or extensibility benefit to JDO over an Entity Bean solution, JDO may still be a better choice, but in our situation, I think that the work required is going to be about the same- you're going to have to do the R to O mapping somewhere.
I think that the benefits of JDO over EB are in the transparency of the persistence, rather than a difference in the amount of work required to state the mapping. For instance, JDO allows persistent classes to be part of an inheritance hierarchy, so that a query can return a heterogeneous collection of concrete subclasses of an abstract class, as long as the query condition can be expressed in terms of persistent fields of the abstract base class. I believe that EJB2.0 can't do this.
As far as performnace goes, I think performance depends on the implementation for both JDO and EB. In any case a lot of performance depends on having sensibly sized transactions and choosing the right isolation level whatever access technology you use.
However, I don't see the database people letting their expertise be replaced by an algorithm written somewhere else.
I'm sure you're right -- I'm lucky, I don't have any 'database people' :-). I think you could make a case for using the default JDO generated schema during development and then designing and mapping the final schema as parts of your object model stabilise -- there's no reason why you can't have a partially automatically generated and partially manually mapped schema.
Tom
|
|
| |
