JDO or O/R Mapper ?

Discussion in 'Java' started by Deepak Nayal, Feb 3, 2004.

  1. Deepak Nayal

    Deepak Nayal Guest

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

    Which one should be used when ?
     
    Deepak Nayal, Feb 3, 2004
    #1
    1. Advertising

  2. "Deepak Nayal" <> wrote in message
    news:bvp19j$vadsk$-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
     
    Silvio Bierman, Feb 3, 2004
    #2
    1. Advertising

  3. Deepak Nayal

    Adam Maass Guest

    "Silvio Bierman" <> 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."
     
    Adam Maass, Feb 6, 2004
    #3
  4. "Adam Maass" <> wrote in message
    news:...
    >
    > "Silvio Bierman" <> 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
     
    Silvio Bierman, Feb 8, 2004
    #4
  5. Deepak Nayal

    Jeff Rhines Guest

    "Silvio Bierman" <> wrote in message
    news:40268299$0$142$4all.nl...
    >
    > "Adam Maass" <> wrote in message
    > news:...
    > >
    > > "Silvio Bierman" <> 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
     
    Jeff Rhines, Feb 11, 2004
    #5
  6. "Jeff Rhines" <> wrote in message
    news:O%pWb.4753$...
    > "Silvio Bierman" <> wrote in message
    > news:40268299$0$142$4all.nl...
    > >
    > > "Adam Maass" <> wrote in message
    > > news:...
    > > >
    > > > "Silvio Bierman" <> 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
     
    Silvio Bierman, Feb 12, 2004
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tom Davies

    Re: best jdo implementation

    Tom Davies, Aug 25, 2003, in forum: Java
    Replies:
    1
    Views:
    331
    Amir Pashazadeh
    Aug 26, 2003
  2. Gerbrand van Dieijen

    Re: best jdo implementation

    Gerbrand van Dieijen, Aug 25, 2003, in forum: Java
    Replies:
    2
    Views:
    918
    =?ISO-8859-15?Q?Alexander=20K=FCken=20
    Sep 10, 2003
  3. Peter

    JDO , JDBC ? ?

    Peter, Jan 1, 2004, in forum: Java
    Replies:
    1
    Views:
    495
    Emmanuel
    Jan 4, 2004
  4. Peter

    JDO ? ?

    Peter, Jan 8, 2004, in forum: Java
    Replies:
    0
    Views:
    559
    Peter
    Jan 8, 2004
  5. Bernd
    Replies:
    15
    Views:
    613
    Chris Smith
    Feb 11, 2004
Loading...

Share This Page