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 15:44:46 -0400
Message-ID: <2006062015444615668-unclebob@objectmentorcom>

On 2006-06-01 14:41:52 -0400, "CMCC" <c_jackal_at_hotmail.com> said:

>> 

>>> No, a DBMS is a bucket of bits with some low level rules to manage
>>> those bits. An OO application provides the beavior that the customer
>>> wants to see. We can completely eliminate the DBMS and replace it with
>>> another of an entirely different form (non Relational for example) and
>>> still have all the business behavior we need.
>>> The people who sell databases have sold you, and the industry, a
>>> misconception: that the database is the heart of the system. This is
>>> flawed. The heart of the system is the application code. The database
>>> is a detail to be decided at the last possible moment and kept in a
>>> position so flexible that it can be swapped out for another at a whim.

>> 
>> 
>> The reason why you see crap like this is because it is being
>> written by application developers.

So it now appears that my statement above was taken out of the newsgroup it was originally posted to, and out of the context within which it was posted, and then crossposted to the newsgroup that would be sure to react most negatively and vehemently against it. Shame on the crossposter.

I don't remember the context of the original post at this point. I can tell you, however, that I fequently give this advice to application developers who have fallen into the trap of deferring all complex behaviors to the database.

Young application designers often begin their designs by drawing a big bubble in the middle of their paper, and labeling it "The Database". Then, as they attempt to partition the behaviors of the system into objects and modules they have this tendency to move complex behaviors into the database bubble: "The Database will handle that". This leads to a nasty impedance mismatch because, often, the database will not handle it.

My advice to these developers is to think of the database as a bucket of bits that they should ignore until the last possible second. Get the application working with mock data first. Build interfaces that allow you to access the data, and stub those interfaces until you can prove the application works. THEN tie in the real database.

The reality, of course, is that there are going to be some real behaviors that the database SHOULD control. Data integrity, referential integrity, etc. Those will become evident as the developers proceed through the design and have to fake these behaviors in the stubs.

-- 
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 - 14:44:46 CDT