Re: Mixing OO and DB

From: Patrick May <pjm_at_spe.com>
Date: Wed, 26 Mar 2008 10:49:33 -0400
Message-ID: <m23aqd5yma.fsf_at_spe.com>

mAsterdam <mAsterdam_at_vrijdag.org> writes:
> Patrick May wrote:
>> 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.

     It's more than regrouping. A different set of behaviors (graph traversal, etc.) are being supported explicitly.

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

     Depending on the transactional context, it may be necessary to update the application state based on database changes. Even if it is, there is a large benefit to having a representation that is more expressive in the context of the application's solution domain.

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

     Actually, there is. Managing dependencies is essential to creating maintainable software.

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

     True. However, the application and the database schema change at different rates and for different reasons. That's a good reason to decouple them.

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

     Those techniques and general patterns like Dependency Inversion allow both the application implementation and the database implementation to be completely replaced without impact to the other component. That's decoupling.

Sincerely,

Patrick

---

S P Engineering, Inc. | Large scale, mission-critical, distributed OO

                       | systems design and implementation.
          pjm_at_spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)

Received on Wed Mar 26 2008 - 15:49:33 CET