Re: JDO or O/R Mapper ?
From: Silvio Bierman (sbierman_at_idfix.nl)
Date: 02/12/04
- Next message: qazmlp: "Re: HAT reports leaks due to JDBC calls"
- Previous message: Philip Michael: "Re: HAT reports leaks due to JDBC calls"
- In reply to: Jeff Rhines: "Re: JDO or O/R Mapper ?"
- Next in thread: Dyre Tjeldvoll: "Re: JDO or O/R Mapper ?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 12 Feb 2004 03:59:36 +0100
"Jeff Rhines" <jrhines@despammed.com> wrote in message
news:O%pWb.4753$ng6.1139@fe2.texas.rr.com...
> "Silvio Bierman" <sbierman@idfix.nl> wrote in message
> news:40268299$0$142$e4fe514c@news.xs4all.nl...
> >
> > "Adam Maass" <adam.nospam.maass@comcast.net> wrote in message
> > news:AaidnRG_D5g_2b7dRVn-gg@comcast.com...
> > >
> > > "Silvio Bierman" <sbierman@idfix.nl> 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
- Next message: qazmlp: "Re: HAT reports leaks due to JDBC calls"
- Previous message: Philip Michael: "Re: HAT reports leaks due to JDBC calls"
- In reply to: Jeff Rhines: "Re: JDO or O/R Mapper ?"
- Next in thread: Dyre Tjeldvoll: "Re: JDO or O/R Mapper ?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
