Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: Robert Martin <unclebob_at_objectmentor.com>
Date: Fri, 2 Jun 2006 01:07:14 -0500
Message-ID: <2006060201071494091-unclebob@objectmentorcom>

On 2006-05-31 11:14:52 -0500, "Mikito Harakiri" <mikharakiri_nospaum_at_yahoo.com> said:

> Robert Martin wrote:

>> Ah, it is so easy to generalize about what one person understands.
>> Are you saying that it is "pure unadulterated garbage" that application
>> developers should isolate their application code from the the whims of
>> the API designers at Oracle?

>
> Database API is SQL.

If only it were so.

> Everything else is auxiliary technology that
> supports it. JDBC is merely a low level programmatic glue between SQL
> and Java, PL/SQL (stored procedures) are the way to enhance SQL with
> programmatic relations (aka functions).
>

>> Should those application designers use
>> every little cute ORACLE trick and call?

>
> Sometimes you have no choice. Consider hierarchical queries, for
> example. Would you go through all the trouble learning/implementing
> nested sets/intervals, materialized path etc, or rather write
> relatively straightforward query based on proprietory "connect by" SQL
> feature?

I would write the straightforward query and then hide it in a lower layer of the application, so that the rest of the application did not need to know about it.

>

>> Or shoudl they stick to
>> standard SQL as proferred by ODBMS or JDBMS, etc.  Should those
>> application developers scatter embedded SQL all through their
>> application code?

>
> This is a culprit that OO people stubbornly refuse to understand.
> Embedding high level language (SQL) statements inside low level
> language (Java) is perfectly reasonable. What you propose instead, a
> pathetic set of classes that build the query dynamically?

I propose a set of classes that uses SQL to do the queries. And then restricting those classes to one well defined layer of the application.  The rest of the application uses that layer through a polymorphic interface so that the layer can be replaced with a different implementation when needed.

>

>> Or should they partition that application code into
>> areas that know about the DB and areas that don't?  Should they strive
>> to make it possible to swap Oracle for MySql or not?

>
> Writing generic SQL might be a good idea, but sometimes you have to use
> proprietory feature. It saves time in a short term.

Granted.

>

>> Should they
>> strive even to eliminate the relational flavor of the data from the
>> guts of their algorithms, or not.

>
> This is rethorical question.

No, it is a very serious question. Actually it is a serious recommendation. As you climb up the levels in an application program you should quickly reach a level where there is no knowledge of SQL. At a slightly higher level there should be no knowledge of tables and rows. Soon thereafter the layers don't even know about the relational schema, and manipulate the data in the form that is most convenient for the application.

-- 
Robert C. Martin (Uncle Bob)  | email: unclebob_at_objectmentor.com
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716                  |

Received on Fri Jun 02 2006 - 01:07:14 CDT