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

From: Robert Martin <unclebob_at_objectmentor.com>
Date: Tue, 13 Jun 2006 13:51:36 +0200
Message-ID: <200606131351367987-unclebob_at_objectmentorcom>


On 2006-06-02 18:07:17 +0200, "erk" <eric.kaun_at_gmail.com> said:

> Robert Martin wrote:

>> It's called decoupling.  Generally it's based on dynamic polymorphism
>> which is a lot of syllables that really mean function pointers.  The
>> idea is that you write the application program in such a way that it
>> can manipulate the data in the data model without coupling it directly
>> to the DBMS, or the details of the schema.

>
> This makes no sense to me - how do you manipulate data without knowing
> the details of the schema?

You transform the data into a form that is more convenient to manipulate. The application can be separated into two layers. One that knows the schema and transforms that data into the application specific form, and the rest of the application that manipulates that data.

> Is it that valuable to have in all cases a
> "mapping layer" with some intermediate form used to moderate?

Not always. But often it is.
Perhaps I would be better off by saying that there are both costs and benefits to the approach, and a good engineer would make the tradeoff on a case by case basis.

> I understand the value of a mapping layer when one is forced to
> interface with applications that have different expectations of data
> format. But what you write above seems to imply that an order entry
> system (e.g.) should have no knowledge of, for example, the fact that
> an order has line items.

Oh, no, not at all. I'm more concerned with the physical representation. The system should certainly know that an order has line items. The system should not necessarily know that this is in the form of two different tables that have certain fields, and are bound by relationship tables, etc.
>

>> The decoupling mechanism is
>> very similar to the mechanism used to create device independence in
>> operating systems like Unix.

>
> I don't think they're at all similar. The interfaces to different
> devices are clearly defined; even if you have a "Unixy" stream, that
> stream is interpreted in specific ways depending on the device type.

True, but applications can be written that do not know what devices they are using.

> I can understand isolating the code which issues the command to the
> DBMS. But to have no knowledge of the schema?

No knowledge of the *physical* schema. E.g. the table names, column names, relationship tables, data forms, etc, etc.

> To isolate knowledge of
> whether you're dealing with XML "data structures", or something generic
> but language-specific, or relations / recordsets / etc? Silly. The
> number of times I've actually seen a need for that isolation, in my 17
> years' experience, is one.

Then you have seen the need.

I have seen it a bit more frequently, but I agree that the need is not universal.

-- 
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 Tue Jun 13 2006 - 13:51:36 CEST

Original text of this message