Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

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

From: Bruno Desthuilliers <bdesth.quelquechose_at_free.quelquepart.fr>
Date: Sat, 03 Jun 2006 21:08:56 +0200
Message-ID: <4481aeb4$0$12746$636a55ce@news.free.fr>


erk a écrit :
> Robert Martin wrote:
>

>>It's called decoupling.  (snip)   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?

It's obvious that at least one part of the application must know that details ('details' as in 'detailed', not as in 'non important'). The idea is to encapsulate this knowledge in one specific part of the application instead of letting it creeps throughout the whole application. And the rational is that it should isolate the application from changes in the RDBMS (schema, vendor, whatever).

Now whether this is a good or bad idea, and whether this even works, is another question.

The fact is that the SPOT rule has proven to be perfectly valid in practice. However, if one wants to strictly apply this rule, this leaves us with a problem: how does one isolate (most of) the application from the RDBMS without duplicating at least part of the business rules already enforced by the RDBMS ? Just using the RDBMS as a dumb persistence mechanism and relying on the application code to enforce the rules is a no-no IMHO - my experience with applications written that way is that it's the road to disaster. OTOH, final users usually expect the visible part of the application to help them doing there job, not let them do things they should not - and to provide useful error messages and effective guidance when the case happens. Of course the RDBMS will catch such errors - but only when the changes are commited. And the RDBMS error messages are usually not really helpful for the final user - nor even for the programmer FWIW. So even if, technically, we could just let the RDBMS take care of all this, this is definitevely *not* what our customers expect from us application developpers.

Someone here claimed that (RDBMS-based) applications should be nothing more than user-friendly substitutes to the RDBMS console. This is of course mostly false [1]. But even in this rare cases of a DB-UI pipeline, there's this "user-friendly" requirement...

[1] a non-trivial part of my job is to build bridges between other applications each using it's own database (in the general meaning, not necessarily a DBMS, let alone a relational one). And of course without any control on the evolutions of the data models, API and whatnot of these applications.

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

In all but the most trivial "DB to GUI tunnel", yes, definitively - at least in my own experience. Having had to maintain two medium-sized applications not following the SPOT rule, I can tell you that no-one in its own mind would want to live such a nightmare. Having to browse thru 50/100 KLOC to make sure the last minor schema change didn't broke anything (needless to say, there wasn't even the slightest automated non-regression test anywhere) is not exactly the way to go if you value productivity (not even talking about programmer's mental health).

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

I definitiveley don't understand it that way. But the detailed knowledge of how this data model lives in the RDBMS - and even the existence of the RDBMS - should certainly not be known to the GUI (or web or whatever) forms. As you say, an order entry system surely has to know that an order has line items - but knowing that there's an 'orders' table and 'lineitem' table with a foreign key on the 'orders' table should only concern a very restricted part of the application.

(snip)

> I can understand isolating the code which issues the command to the
> DBMS. But to have no knowledge of the schema? To isolate knowledge of
> whether you're dealing with XML "data structures", or something generic
> but language-specific, or relations / recordsets / etc? Silly.

Not necessarilly. This mostly depends on the application, in fact. But I'm certainly not as 'extreme' as Robert Martin on this point. Usually, when one of my apps uses a RDBMS, I try to make an effective use of it, not to hide it away - else, the app would probably be better not using a RDBMS at all. But still I try to isolate the part of the application that need to know this from the part that don't. As Robert Martin says, this is called "decoupling". Received on Sat Jun 03 2006 - 14:08:56 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US