JDO or O/R Mapper ?

[Deepak Nayal]

Can anybody please let me know what is the difference between
JDO(Implementation) and O/R Mapper ?

Which one should be used when ?

 

[Silvio Bierman]

Can anybody please let me know what is the difference between
JDO(Implementation) and O/R Mapper ?

Which one should be used when ?

I would say JDO is an API specification for a particular class of O/R
mapper. Both can be used when you insist on creating a transparant but
suboptimal way to store data that is contained in Java objects in a
relational database...

Silvio Bierman

 

[Adam Maass]

I would say JDO is an API specification for a particular class of O/R
mapper. Both can be used when you insist on creating a transparant but
suboptimal way to store data that is contained in Java objects in a
relational database...

I am interested to know why you consider O/R mappers "suboptimal."

 

[Silvio Bierman]

I am interested to know why you consider O/R mappers "suboptimal."

Only in rare cases do I need persistance of an object that is part of an
application and when I do it is never meant to go into a relation database.

I often need a well designed relational database and an evenly well designed
application that makes use of that same database. OR mappers imply that you
map the state of an in-memory object to a relational database. That is
simply not the same and loften eads to poorly designed databases which
mirror the logical structure of memory objects instead of the information
structure of the problem domain. Besides that the actual database access is
worse than when handcoded with over-reuse of a single access path for
different types of data needs that had been better served with specific
access code.

In my opinion OR mappers are not worth the trouble. The many projects where
I have been brought in to solve performance problems caused by the use of
entity beans, hibernate, toplink etc. only serve to prove my case.

Silvio Bierman

 

[Jeff Rhines]

Only in rare cases do I need persistance of an object that is part of an
application and when I do it is never meant to go into a relation

database.

I frequently need to persist a data object. I never need to persist a
purely functional one.

I often need a well designed relational database and an evenly well designed
application that makes use of that same database.

Personal experience only, but i have yet to see a truly object-oriented
application that only uses straight access to an RDBMS. The code always
ends up being "component-oriented", and can even be well-modularized, but
the code i've seen has never qualified as object-oriented. That is, you
could not have described it as something resulting from an object-oriented
analysis of the problem domain.

OR mappers imply that you
map the state of an in-memory object to a relational database. That is
simply not the same and loften eads to poorly designed databases which
mirror the logical structure of memory objects instead of the information
structure of the problem domain.

Ok, the classic start of a counterargument here... "Not Necessarily" :]
There are several classic strategies for creating well-designed schemas
based on the object-oriented data that you intend to persist. The most
difficult problems, including polymorphic queries and collections, have
already been solved many times over. Personally i use Hibernate because of
the price tag, but there are plenty of others out there that do as good of a
job and don't require you to use poorly designed database structures.

Besides that the actual database access is
worse than when handcoded with over-reuse of a single access path for
different types of data needs that had been better served with specific
access code.

Again, not necessarily. Look at it this way instead... there is a "right"
way to pull your data in and represent it in memory, yes? Well, why would
that "right" way be different from table to table? So if we agree the
strategy is going to be the same, why couldn't a good O/R API author code
the related algorithms and apply the strategy generally to all in-memory
representations of data?

In my opinion OR mappers are not worth the trouble. The many projects where
I have been brought in to solve performance problems caused by the use of
entity beans, hibernate, toplink etc. only serve to prove my case.

Ah... your experience is definitely valid. However, i would argue that it
wasn't the technology's fault that it was originally applied improperly.

Regards,
Jeff

 

[Silvio Bierman]

database.

I frequently need to persist a data object. I never need to persist a
purely functional one.


Personal experience only, but i have yet to see a truly object-oriented
application that only uses straight access to an RDBMS. The code always
ends up being "component-oriented", and can even be well-modularized, but
the code i've seen has never qualified as object-oriented. That is, you
could not have described it as something resulting from an object-oriented
analysis of the problem domain.

I think you nailed the spot here. In my opinion a non-trivial application
should be designed top-down, meaning that you first design the global
architecture (server components, client components, communication protocols,
relational database structure and partitioning) and then start worrying
about implementing the individual parts. On that level, OO is a non-concept,
it just does not play a role.
When you start implementing a component (server, client, utility classes
etc.) OO comes in. It helps writing maintainable quality code as well as
code reuse (which is always low-prio, code-reuse for the sake of it is as
bad as code-optimization for the sake of it). OO should not cross component
boundaries since as I said it must never influence architecture (I never
mean "code" when I use this word).

Many projects go bad because people start doing things the other way around.
They do not design an archtitecture but start with selecting tools: "let's
use Toplink on Oracle, Rational Rose for the UML stuff, Struts for the
Web-UI etc.). After that they completely loose themselves in the UML part,
start generating code, serialize "data objects" into the dbms and mock up a
prototype. After some tweaking it works, they are very satisfied with the
sleek combination of tools they used and the real work starts: extending the
proto to a real functional application. More programmers are brought in and
many heated discussions at the whiteboard about UML diagrams can be heard.
After some time/money the application has become humongously bloated,
performs bad and gets ever harder to extend. Finally the functional demands
are loosened to "finish" the project. A new customer for "the big iron" is
born when the database grows and a normal PC server no longer suffices.

OR mappers imply that you
map the state of an in-memory object to a relational database. That is
simply not the same and loften eads to poorly designed databases which
mirror the logical structure of memory objects instead of the information
structure of the problem domain.

Ok, the classic start of a counterargument here... "Not Necessarily" :]
There are several classic strategies for creating well-designed schemas
based on the object-oriented data that you intend to persist. The most
difficult problems, including polymorphic queries and collections, have
already been solved many times over. Personally i use Hibernate because of
the price tag, but there are plenty of others out there that do as good of a
job and don't require you to use poorly designed database structures.

My point is that you turn things around. A dbms is not for persisting your
objects, application code (OO or not) is for making data in a dbms
accessible in a meaningfull way. I do not argue that it is possible to do
efficient object serialization through a dbms if you consider the dbms a
means and serialization an end.
In my opinion a well designed architecture contains a to-the-point database
design based on thorough information analysis. That database (which is in
all but simple cases also to be accessed by other programs and tools) is an
important deliverable on itself. Having anything in that database reflect
design decisions made in the application code would be a mistake. I prefer
to use a separate database as a scratchblock for storing trivia like user
settings/preferences etc. to not mess up the actual database.

Again, not necessarily. Look at it this way instead... there is a "right"
way to pull your data in and represent it in memory, yes? Well, why would
that "right" way be different from table to table? So if we agree the
strategy is going to be the same, why couldn't a good O/R API author code
the related algorithms and apply the strategy generally to all in-memory
representations of data?

Absolutely not. There is never a right way, it always depends on the
situation. If I need a customer to be accessed as a "record" a SELECT of the
needed columns based on a primary key would be the right way. If I need a
list of customers in a geographic area I need a SELECT of some display
columns for multiple customers filtered on area code or something and
preferably ordered by the dbms. If I need a customer name column in a list
of orders I want a join on the order and customer tables.

The problem with using "generic" database access is that most of these
scenarios end up being served with a sub-optimal access path.

Ah... your experience is definitely valid. However, i would argue that it
wasn't the technology's fault that it was originally applied improperly.

It never is...

Seriously, I think that folklore is the biggest drive in decisions made by
software architects. People are tought to think in terms of "the right tools
for the job". I roam the newsgroups for amusement about the many heated
debates about Struts versus JSF versus ASP.NET and Toplink versus JDO versus
Entity beans, SOAP versus RMI versus Corba.

Seldom dowe see discussions about whether or not to use a HTML UI versus a
traditional GUI, which application protocal to use and what transport
protocal etc.

The key performance factors of most applications are things like database
access and communication protocols. Programmers should stop abstracting them
away by using tools that make them transparent. In the end they only master
the tools instead of the essentials...

Regards,
Jeff

Regards,

Silvio Bierman