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

From: Robert Martin <unclebob_at_objectmentor.com>
Date: Tue, 20 Jun 2006 13:22:29 -0400
Message-ID: <200606201322297826-unclebob@objectmentorcom>

On 2006-06-13 09:32:58 -0400, "erk" <eric.kaun_at_gmail.com> said:

> Robert Martin wrote:

>> Functionality can be split between many modules.  Given a particular
>> functionality, part of it will be SQL related, and part of it will not.

>
> The word "functionality" is troubling. Presumably the underlying domain
> objects are the core of the application, and therefore not something
> that can be hidden away from other modules - those modules mostly
> depend on the domain objects, right? And if those are state-bearing
> objects (if not they're not really objects), then they're data
> structures. Just very feeble ones.

Application objects can be hidden from each other, and just exposed through narrow interfaces. Domain objects do not (and should not) contain application specific functions. Any methods within them must be global to the enterprise. Even so, they should be exposed to each application through a narrow interface that hides all the methods that this application is not interested in.

>

>> We would like those two parts to be separated at the source code
>> level, with the dependencies pointing AWAY from the SQL modules.  This
>> allows us to change out the data management technology (if not the
>> theory),

>
> I think I agree with you here, but would like some more explanation.
> What do you mean by "if not the theory"? The different "storage
> technologies" have very different data models - do you advocate
> sticking to one of them for a given application, or a given business
> domain?

I was saying that swapping out the theory is optional. You may swap one RDB for another. Or, at some level, you might swap RM for some other data modeling technique.

>> and also test the application code without running the DB.

>
> If the language itself included the ability to define relations and
> constraints (and obviously keep those in sync with the DBMS), this
> would be equally easy.

True. However, our languages don't seem to be moving in that direction.  Nor am I convinced that they should. While RM is a powerful technique for structuring data, I am not convinced that it is a powerful technique for structuring behavior.

>

>>> I don't challenge your goal, but relational model abstractions are too
>>> sophisticated to give up to such primitive methods.
>> 
>> Nobody is talking about giving anything up.  The position of a line of
>> code does not limit it's power.  The fact that we want the SQL in
>> source modules that are independent, does not mean that they can't be
>> used all through the application.

>
> So you're still talking about "mapping" SQL to objects, which won't
> have (or will have re-implementations of) the constraints and types in
> the database?

Render unto Ceasar. I have no problem with integrity rules being enforced by the database so long as they do not interfere with the testability of the application. However, any *application specific* constraints should be managed by the application instead of the database.

>>> Striving to make
>>> your application database agnostic results in the flaws which expose
>>> designers data management ignorance.
>> 
>> I disagree.  Striving to separate your application into database
>> dependent and database independent partitions enhances flexibility and
>> testability, without reducing power.

>
> Would having easier-to-use DBMSs, even in-memory ones, do the same for
> you?

No, I value the separation for it's own sake, not because of any particular tool.

> I agree with enhancing testability, though I'm not sure what you
> mean here by flexibility - in "storage technology"?

Flexibility is the ease with which we can make a fundamental change to the application, like swapping out the RDBMS for a flash card.

> By that, do you
> mean just switching from Oracle to Postgres or vice versa, for example?

Among other things, yes.
>

-- 
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 20 2006 - 12:22:29 CDT