Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > JDO or O/R Mapper ?

Reply
Thread Tools

JDO or O/R Mapper ?

 
 
Deepak Nayal
Guest
Posts: n/a
 
      02-03-2004

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

Which one should be used when ?


 
Reply With Quote
 
 
 
 
Silvio Bierman
Guest
Posts: n/a
 
      02-03-2004

"Deepak Nayal" <(E-Mail Removed)> wrote in message
news:bvp19j$vadsk$(E-Mail Removed)-berlin.de...
>
> 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


 
Reply With Quote
 
 
 
 
Adam Maass
Guest
Posts: n/a
 
      02-06-2004

"Silvio Bierman" <(E-Mail Removed)> wrote:
>
>
> 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."


 
Reply With Quote
 
Silvio Bierman
Guest
Posts: n/a
 
      02-08-2004

"Adam Maass" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> "Silvio Bierman" <(E-Mail Removed)> wrote:
> >
> >
> > 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."
>
>


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


 
Reply With Quote
 
Jeff Rhines
Guest
Posts: n/a
 
      02-11-2004
"Silvio Bierman" <(E-Mail Removed)> wrote in message
news:40268299$0$142$(E-Mail Removed)4all.nl...
>
> "Adam Maass" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> >
> > "Silvio Bierman" <(E-Mail Removed)> wrote:

> 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


 
Reply With Quote
 
Silvio Bierman
Guest
Posts: n/a
 
      02-12-2004

"Jeff Rhines" <(E-Mail Removed)> wrote in message
news:O%pWb.4753$(E-Mail Removed)...
> "Silvio Bierman" <(E-Mail Removed)> wrote in message
> news:40268299$0$142$(E-Mail Removed)4all.nl...
> >
> > "Adam Maass" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > >
> > > "Silvio Bierman" <(E-Mail Removed)> wrote:

> > 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.
>


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.

> > 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?
>


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.

> > 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.
>


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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
What do you think about JDO? Bernd Java 15 02-11-2004 05:26 AM
JDO ? ? Peter Java 0 01-08-2004 09:21 AM
JDO , JDBC ? ? Peter Java 1 01-04-2004 11:18 PM
Re: best jdo implementation Gerbrand van Dieijen Java 2 09-10-2003 02:40 PM
Re: best jdo implementation Tom Davies Java 1 08-26-2003 12:58 PM



Advertisments