Re: OO and relation "impedance mismatch"
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