Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!newsfeed.internetmci.com!howland.reston.ans.net!surfnet.nl!sun4nl!news
From: mzomer@inter.nl.net (mzomer)
Subject: Re: Persistency FrameWork
X-Nntp-Posting-Host: ztm99-4.zoetermeer.nl.net
Message-ID: <Do0Du4.MB5@solair1.inter.NL.net>
Sender: news@solair1.inter.NL.net (News at news)
Reply-To: mzomer@asd.bso.nl
Organization: ORIGIN
X-Newsreader: WinVN 0.93.9
References: <DnpM7J.4vL@solair1.inter.NL.net> <4hlfqr$fov@steel.interlog.com> <Dnx11x.2IL@solair1.inter.NL.net> <knight.826323894@tina.mrco.carleton.ca>
Mime-Version: 1.0
Date: Sun, 10 Mar 1996 01:25:32 GMT
Lines: 143


Alan,

In article <knight.826323894@tina.mrco.carleton.ca>, 
knight@mrco.carleton.ca says...
>
>In <Dnx11x.2IL@solair1.inter.NL.net> mzomer@inter.nl.net (mzomer) 
>writes:
>>       1. The product genrates code which is added to the business
>>          objects...

>I'm not sure how you got this impression, but it's not true. TOPLink
>requires you to write a "descriptor" for each persistent class. This
>is essentially the meta-model you talk about below. 

You're right, TOPLink does not generate code. I made the wrong
assumption.

>This descriptor is
>typically written as a class method, but this is only because it's a
>convenient place to put it. We have clients who read these descriptors
>from a database on system startup, so they end up not being
>image-resident at all.
It might be convenient to add the description as a class method to
the business object but it is terrible wrong! You have to sepperate
external interfaces from the business object model. Nobody adds
methods to a business object to display itself on a GUI, most
programmers use the MVC paradigm to accomplish that. One
golden rule is that the model (business object) does not
know anything of the surrounding world. Putting a description, or
to be more precisely a mapping from the object to a RDBMS table,
in the business object violates this rule.
So the description has to be sepperated from the business object
model. I've seen several solutions for a persistency framework
and most of them make the same mistake!


>>       2. The product also enforces business object to have a KEY,
>>          sorry, but that not Object Oriented at all.....

>No, it's not object-oriented. It's relational. If I have an object in
>memory that corresponds to one or more relational rows, I need a way
>to find which rows to update. That means I need a key. The key can be
>completely arbitrary (it's often generated by the database) and the
>application can ignore it, but it's the translation into relational
>terms of object identity. I guess we do affect the business objects in
>that the key is generally stored as an instance variable, but I would
>characterize this as minimal.

The fact that you need a key to identify the persistent object in the
database is right, but this piece of information can also be stored
somewhere else. As you say: "The key can be completely arbitrary (it's
 often generated by the database)", is also a good reason to sepperate
this information from the business object.

>>A way to solve the mapping from a businnes object model to a
>>RDBMS is using a Meta Model which describes your business object
>>model including relations. Smalltalk itself does not has explicit
>>support for relations. Using the Meta Model and a description in 
>>Smalltalk of the database structure (this is also a Meta Model)
>>your able to map object ID to keys.

>How do you propose to do this mapping from object ID to keys? Object
>identity is a lovely property, but it doesn't easily generate
>something that can be stored in a relational database.

To map objects to a rational database you need four things:

	1. A Meta Model describing the business object model;
	2. A Meta Model describing the database;
	3. A static map, mapping business objects to database tables;
	4. A dynamic map, mapping object instances to rows (== keys).

When you retreive a row from the database you use the static map
and the Meta Model to instantiate an object. At that point you
have references to both worlds in one hand, so put this information
into the dynamic map. If you want to delete or update an object you
use the dynamic map to find the corresponding row in the database.
The static map is used to translate instance variables to columns.

You asume that the object model is leading in defining the
database layout. If that were true all the time you need
some mechanism the generate a key in a database table. In
our situation we also have many other applications that
are not object oriented who have access to the same database.
We have some influence on the definition of the database
layout but in some cases we have to deal with an existing
database.


>>The code you need to store or retreive objects can be generic,
>>so you do not need to generate code.

>And we don't.

You're right, I assumed the descriptions were generated.

>It's possible that when you talk about generating code you mean our
>descriptor generator. This is not generating code for the domain
>objects, it is generating the meta-model automatically by examining
>the objects.

So after all you do generate the descriptions?

>I think you have misconstrued how TOPLink operates. If you contact us
>I'm sure we can clear up any misunderstandings. If you don't like
>TOPLink, that's fine, but I'd hate to have you reject it as a solution
>based on a misunderstanding.

I do not reject TOPLink based on misunderstandings, I reject TOPLink
because there is no clean sepperation between object model and
the relational database. I think TOPLink is on the right way but
you have to make one more step. Build a persistency framework
that maps a busisness object model to a RDBMS without screwwing
up the business object model.
In large business application we have to deal with many types
of persistency and we can not allow products like TOPLink to
have any impact on our business object model.

My major problem with solutions like TOPLink is that there is
no clean sepparation between business object model and the
way the model is made persistent.

Interfaces to external systems have to be sepperated from
the business object model, so you send a message to an
instance of a persistency framework that it has to store
an object and not sending the message to the object itself!!
As you know, there are more external interfaces than
a persistent storage alone. You have a GUI, a mechanism to 
transfer an object via TCP/IP to another location etc.

I hope I made clear that making objects persistent is
more than just adding some code to the objects itself.
You have to build a real Framework that sepperates
interface from implementation.


CU


--martin


