Re: Mixing OO and DB

From: mAsterdam <>
Date: Tue, 25 Mar 2008 17:01:00 +0100
Message-ID: <47e9216d$0$14361$>

Patrick May wrote:
> mAsterdam writes:

>> Patrick May wrote:
>>>      The fact that views can be used actually demonstrates that the
>>> application can be decoupled from the schema.
>> Imagine trying to provide an example to illustrate the level of
>> decoupling. I think we'ld wind up with aliases to refer to a subset
>> of the same data the schema describes - or are you talking about
>> more radical decoupling?

> If the application implements the solution using a DAG, for
> example, and the state of each node in the DAG is stored in a
> relational database, then a mapping between the two models must take
> place.

The data is regrouped. Not a huge decoupling, but yes, more than just aliasing.

Barring design flaws, your examples deals with two applications using the same data: the one that deals with the individual nodes and the one that deals with the DAG as a whole. Should changes in the individul node states outside the influence of the current application be reflected in it? Not a big decoupling, yet there is already a price-tag.

> If the application changes the way it uses its internal model,
> that shouldn't have an impact on the schema.

There is no "should" or "shouldn't" here. As long as the application uses the same data, the change won't impact the schema, and if there are changes in the data requirements, it will. No design approach or tool-stack will help you avoid the inevitable.

> If the schema is changed
> but still provides sufficient data, albeit possibly in a different
> form, to instantiate the DAG nodes, that shouldn't impact the
> application logic. Only the mechanism that provides the decoupling
> between the two, typically an ORM layer, needs to change in a well
> designed system.

>>> application can be decoupled from the schema.  You are suggesting
>>> using views to do so.  That's one possible mechanism.  OO languages
>>> provide others.
>> Which?

> ORM tools, DAOs, and caches, for example.
These provide decoupling in names, shape and actuality of the data.
I would not call that decoupling from the schema - the schema still describes the data itself. Is that the whole problem? Labeling something as decoupling or not? Received on Tue Mar 25 2008 - 17:01:00 CET

Original text of this message