Re: OO and relation "impedance mismatch"

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sun, 03 Oct 2004 18:44:51 +0200
Message-ID: <41602c83$0$78753$e4fe514c_at_news.xs4all.nl>


Fredrik Bertilsson wrote:

>>>... I would make (or generate) one class for each table
>>>and use SQL queries for retrieving records/objects.
>>>Why can't tables and records be considered as "objects"?
>>
>>They are different things, they serve different
>>purposes. The tables hold data (meaningful in
>>their own right)

> 
> Sorry, I don't follow you here. Every OO design I have seen have
> objects have been mapped to tables. If you have a class named
> "Customer", you will most likely also have table named "Customer".

Yep. They are not the same - are you saying they are?

>>the objects behave, only need
>>data to do what it is they are supposed to do.
>>...object only needs data necessary for
>>its required behaviour.
>
> It sound like you are talking about functions.

The objects' behaviour, including data-access are coded as methods, messages, member-functions or whatever synonym is the favorite in the language of choice.

What else?

>>Only when an object needs to be remembered
>>after it dies (for a possible next incarnation),
>>all data necessary for it's later revival must
>>get out of the (object-context of) the running
>>program into the database.

> 
> I disagree. In a multi-user environment, changes must be 
> availible as soon as possible for the other users. 
> If you are not using stuff like Entity EJB, this
> means that the changes has to be written to database
> as soon as possible.

Only the changes which may be relevant to to the other users need to be available asap - not, for instance a part of an item the user is currently filling in. Application frameworks take care of the selection of which changes should result in database transactions for you.

But I don't really see a reason for disagreement in your statement. Effectively you are saying that all objects must be prepared to die revivably at any point in time - this could be a requirement for a very robust system. Any change, not matter how small, to any object, must result in a database transaction in such a sytem. Received on Sun Oct 03 2004 - 18:44:51 CEST

Original text of this message