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

Bruno Desthuilliers wrote:
> 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).

This doesn't answer the question, though: how do you manipulate data without knowing the details of the schema? For an application to contribute usefully to the manipulation of some data, it has to know how that data is structured. As a simple example, if you have a data structure for customers, and a data structure for polygons, you cannot have code that doesn't know which one it is working on. The code cannot be abstracted away from the question of whether it is an order entry system or a geometry engine.

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

What, you can't build a user-friendly view if the model is an RDBMS, but you can if it's objects?

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

Let's rephrase that slightly:

"an order entry system surely has to know that an order has line items"

An order entry system has to know that there exists a set of orders, and that each order has a set of 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."

but knowing that there's a set of orders, and that each order has a set of line items should only concern a very restricted part of the application.

I cannot make sense of this. The app must know that there exists a set of orders, but knowledge of the orders table, which is nothing more than a set of orders, must be restricted. Why?

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

Agreed.

Marshall Received on Sat Jun 03 2006 - 18:10:47 CEST