Re: Mixing OO and DB

From: Robert Martin <unclebob_at_objectmentor.com>
Date: Thu, 14 Feb 2008 09:57:27 -0600
Message-ID: <2008021409572750073-unclebob_at_objectmentorcom>


On 2008-02-13 06:07:58 -0600, "David Cressey" <cressey73_at_verizon.net> said:

>
> "Robert Martin" <unclebob_at_objectmentor.com> wrote in message
> news:2008021221010631729-unclebob_at_objectmentorcom...

>> On 2008-02-11 16:21:12 -0600, "David Cressey" <cressey73_at_verizon.net>

> said:
>> 
>>> Objects do not always hide data.  Specifically,  they pass messages to

> each
>>> other in the form of data.
>> 
>> True, but the recipient has no guarantee that the data recieved was
>> stored anywhere. Nor can the recipient be sure that the recieved data
>> originated in the recieved form.   Moreover, the sender expects the
>> recipient to do something with the data.  All messages connote action
>> of some kind.
>> 

>
> It's the recipient's job to store the data, in general.

No, a recipient *might* store it. Or it might use the data as an index to look up something else. Or it might multiply it by 42, convert it to hexadecimal, and send it to a text to speech device.

> In
> many contexts, we like to think of the recipient of a query as the client
> process that partners with the DBMS as a server process. In reality, the
> receiver is a transaction, not a process.

Quite. The transaction is an object. It recieves messages from the client and performs certain behaviors based on those messages. The transaction has some state information buried in it; but the clients are not privy to the form of that data. We can ask a transaction whether it is dirty or not, or whether it is open, or complete, but the form of that state information is hidden deep inside the transation and passed out in a form suitable for client consumption. That's how objects behave.

-- 
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 Thu Feb 14 2008 - 16:57:27 CET

Original text of this message