question about passing object references,Me and serialisation

Hi,

I have a class called Person. It inherits from a base class PersistentObject
that exposes Load() and Save() functions and contains an ObjectID.

I WANT to write the Load() method like this:

class PersistentObject
sub Load()
PersistentManager.LoadObject(Me) 'where Me is a By Ref parameter
end sub

The persistence layer uses .NET serialisation to return a populated object,
based on the persons ObjectId which must be populated when Load() is called.
(or does a refresh). It also examines other properties of the PersistentObject,
such as whether this is a proxy object or not.

Now the problem. Me cannot be assigned a new object. Likewise making the
parameter in LoadObject() By Ref and passing it Me does not work (interestingly
it compiles without complaint but simply does not change).

So I have resorted to making Load() a method that returns the newly loaded
object, meaning I have to write the ugly code:

class PersistentObject
function Load()
dim oObj as PersistentObject
oObj=PersistentManager.LoadObject(Me)
return oObj
end function

and in the main program:

person=person.Load()

when what I want to be able to write is
person.Load()

It's nice having Load() a method of the object, rather than having to call
a function in the persistance layer. Any idea's on how I could get the object
to change itself to the new object, within the Load() method, or solve this
design problem someother way? Guess I am missing something because this must
be a common scenario :)

If not I guess the best thing is to put a method on the PersistanceManager
so I can write
PersistenceManager.Load(person)
Then there are no problems having Person being passed by ref and returning
a new object. (PersistenceManager is a singleton)

Any ideas?

Thanks,
Will

"will" <williamfleming@hotmail.com> wrote in
news:3db0fce4$1@tnews.web.devx.com:

>
> Hi,
>
> I have a class called Person. It inherits from a base class
> PersistentObject that exposes Load() and Save() functions and contains
> an ObjectID.
>
> I WANT to write the Load() method like this:
>
> class PersistentObject
> sub Load()
> PersistentManager.LoadObject(Me) 'where Me is a By Ref parameter
> end sub
>

I'd say, without any deeper analysis, that this is a good candidate for a
shared method on the Person class.

If not, Load would set the properties on the object itself, rather than
creating a new object and trying to return that.

--
Rune Bivrin
- OOP since 1989
- SQL Server since 1990
- VB since 1991

The common scenario is to use a 'Manager' to retrieve (load) an object.

A persistant frame work on another OO platform uses an Object ID and the
object type to 'load' and return the object. For example:

Person person = ManagerFactory.getPersonManager.retrieve(new ObjectID(1))

(Person being an interface and PersonMangager being returned as an interface)

I wouldn't inherit Person from PersistentObject.

"will" <williamfleming@hotmail.com> wrote:
>
>Hi,
>
>I have a class called Person. It inherits from a base class PersistentObject
>that exposes Load() and Save() functions and contains an ObjectID.
>
>I WANT to write the Load() method like this:
>
>class PersistentObject
> sub Load()
> PersistentManager.LoadObject(Me) 'where Me is a By Ref parameter
> end sub
>
>The persistence layer uses .NET serialisation to return a populated object,
>based on the persons ObjectId which must be populated when Load() is called.
>(or does a refresh). It also examines other properties of the PersistentObject,
>such as whether this is a proxy object or not.
>
>Now the problem. Me cannot be assigned a new object. Likewise making the
>parameter in LoadObject() By Ref and passing it Me does not work (interestingly
>it compiles without complaint but simply does not change).
>
>So I have resorted to making Load() a method that returns the newly loaded
>object, meaning I have to write the ugly code:
>
>class PersistentObject
> function Load()
> dim oObj as PersistentObject
> oObj=PersistentManager.LoadObject(Me)
> return oObj
> end function
>
>and in the main program:
>
> person=person.Load()
>
>when what I want to be able to write is
> person.Load()
>
>It's nice having Load() a method of the object, rather than having to call
>a function in the persistance layer. Any idea's on how I could get the object
>to change itself to the new object, within the Load() method, or solve this
>design problem someother way? Guess I am missing something because this
must
>be a common scenario :)
>
>If not I guess the best thing is to put a method on the PersistanceManager
>so I can write
> PersistenceManager.Load(person)
>Then there are no problems having Person being passed by ref and returning
>a new object. (PersistenceManager is a singleton)
>
>Any ideas?
>
>Thanks,
>Will
>
>
>
>
>
>

Hi Mark, Thanks for your reply.

I am using a Manager - the PersistanceManager object called by PersistantObject.Load().
I guess there is a difference of philosophy here - should an object know
everything about how to persist itself, in which case I should be able to
write Person.Load() and require no knowledge of the Manager class, or is
it better to force the client code to call the MangerFactory as you suggest,
which requires the client code to have knowledge about the ManagerFactory:

>Person person = ManagerFactory.getPersonManager.retrieve(new ObjectID(1))
>

One question about ManagerFactory - Does it return a separate interface for
every kind of data class? Does this mean if you add a new data class to the
application, you need to modify ManagerFactory code? That is what I was hoping
to avoid by writing a "ManagerFactory" (I have called it PersistenceManager)
that works only with the base class PersistentObject and has no knowledge
of individual data classes. As I only require simple persistence using .NET
serialization I was hoping this was a feasible design. Feels so much nicer
than a persistence layer that requires changing everytime I add/modify/delete
a data class!

cheers,
Will

Hi Rune,

Thanks for your reply.

>
>I'd say, without any deeper analysis, that this is a good candidate for
a
>shared method on the Person class.

The Load() function can also refresh an existing person. So I think it's
better if you can go person1.load() person2.load() etc rather than making
load a shared function. Though its an interesting idea I hadn't though of
before...

>If not, Load would set the properties on the object itself, rather than

>creating a new object and trying to return that.

I agree this is what would normally happen if you were pesisting to a relational
database for example. The problem is .NET serialisation returns a whole new
object from the Deserialize() function. I guess I could then take that object
and manually copy the data into the existing objects properties, but that
starts getting messy if your object contains a collection of child objects
which also contain objects and so on. Thats what serialization is supposed
to magically take care of for free!

In a pure OO world, I would say you are right, the Object should know how
to persist itself. It won't work the way you want it to though. You do
want to hide the persistance mechanism. So how does one go about it? What
are the ways something can be persisted? We can't name them all but let's
try:
Serialized object (binary), XML Serialization, RDBMS, O/R Mapping, ODBMS,
Files, Heirchical DB, Retrieved via Messaging, veriations of each, and a
combination of each of these. Each of these brings its own issues. Today
you are doing object serialization. How about tommorrow? We cannot see
tomorrow. History shows us that if we don't prepare for tomorrow, we won't
be prepared. Som what will work for one may not work well for the other


The most common thing is to do it the way I showed and then implement as
needed. The problem is that you are instantiating one object then replacing
it with another. Just because the object is not persisted doesn't mean it
doesn't exist.

Ok, while I was hacking this I was thinking too. How about this -

Person person = Person.load(new ObjectId(1));

// method in Person class
public static Person load(ObjectId objectId)
{
return ManagerFactory.getPersonManager.retrieve(objectId);
}

//Method in PersonManagerSerializedObject (which implements PersonManager)
public static Person retrieve(ObjectId objectId)
{
return (Person) PersistentManager.LoadObject(new Person(objectId));
}


//Method in ManagerFactory
public static PersonManager getPersonManager()
{
// Either by reflection (prefered for flexibility - I'll give you an excellent
example if you want) or by instantiating the concrete class, return the current
PersonManager which would be PersonManagerSerializeObject
}


Ok the reason that you should probably call the factory and manager to get
the Person object is because the person Object should be returned as an
interface too. So i.e. Person should be an interface and PersonSerializeObject
will implement it. The controller class should also as the Manager for a
new instance. You may not see a reason for this today, but as .Net matures
more persitance frameworks will come available it will future proof you.
(For reference, check out Java persistance frameworks).

We are doing this with excellent results. We have 'psuedo heavy' clients.
I want to be able to design my app without worrying about implementation
details so I write it as if everything is on the same machine but hide the
details but also with multiuse in mind. Then I think about distributing
the app and how and where things should run. Then I write custom Managers/Classes
or whatever for the need and then distribute. This explanation is some what
simplistic - but these technique works. .Net throughs a wrinkle into because
you gotta know what exceptions will be thrown. The way around that is to
catch those exceptions and only throw what the interface docs say can be.

Here is a good link. Sorry it is in Java but the principles are the same.
http://www.javadude.com/articles/

Hi Mark.

Thanks very much for your informative message. You are suggesting a fairly
major architectural change! I'll think it all over, read some more articles
and let you know what happens.

Will

You're welcome. I've tried this in different ways and different languages
and have come up with this. Yes, it might be an architectual change now,
but it will prevent more and more painful ones in the future.

Mark


"will" <williamfleming@hotmail.com> wrote:
>
>Hi Mark.
>
>Thanks very much for your informative message. You are suggesting a fairly
>major architectural change! I'll think it all over, read some more articles
>and let you know what happens.
>
>Will
>
>
>