Serialization of Complex objects

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Nate - 18 Jun 2004 12:53 GMT

I am creating an application that is quite complex. There will be several
dozen objects, most of which have delegates defined. At runtime, there will
be several hundred instances of some objects and many dozens of instances of
other objects (e.g. 100+ ClassA's, 10+ ClassB's and 50+ ClassC's etc). At
runtime though, some objects will be configured to make callbacks to other
objects, but this is defined at RUNTIME though.

I want to be able to save these "object relationships" to disk though, and
I'm scared to use serialization. I've seen the horror stories of
serialization on complex/large apps (like this one) and the size/space/time
the serialization-process took... I've also seen custom serialization and
I'm not sure about that yet, but might have to resort to it, but would still
then come back to this particular question though I'm sure...

Does anybody know of an easy way of storing these "object relationships" to
a file so that I can load them and re-establish the links (object
relationships) later ???

I've tried creating an arraylist and populating it with the delegate
invocation list members from a single object and that worked great as far as
persisting that information to a file. I could load that information back
into my object delegates (this all in a test-app of course) and could see
the delegates back in the invocation list of that delegate, but the
callbacks were not made to the target(s) when I invoked the delegate though.

My guess is that the address of the object (target) is different to what was
persisted.

I'm thinking of having some kind of "naming" structure where I can pinpoint
an object by a name for example
"objecta.subObjecta.subSubObjectb.Method" --- but this might be a tough one
to implement.

Anybody have any ideas?

I'm using VB.NET 2003.

Thanks.

Nate.

Reply to this Message

Richard Grimes [MVP] - 22 Jun 2004 19:37 GMT

> I want to be able to save these "object relationships" to disk though, and
> I'm scared to use serialization. I've seen the horror stories of
> serialization on complex/large apps (like this one) and the size/space/time
> the serialization-process took...

The space/time penalty is something you'll have to bear if you want the
complete information about the objects stored.

> I've also seen custom serialization and
> I'm not sure about that yet, but might have to resort to it, but would still
> then come back to this particular question though I'm sure...

Custom serialization is really only useful if you are trying to serialize
objects that have members that are obviously not serializable (for example a
file handle - you can use custom serialization to give information about the
file so that a new handle is created at deserialization time).

> Does anybody know of an easy way of storing these "object relationships" to
> a file so that I can load them and re-establish the links (object
> relationships) later ???

The best way is to use the built in serialization. That's what its designed
to do. If you try and roll your own you'll find it complex. For example,
serialization uses something called the object manager that maintains
relationships so that if you have multiple references to one object, the
object is only serialized once, but the 'references' in the other objects
are still serialized. When the object is deserialized the object manager
works out whether a 'reference' is to an object that has already been
deserialized, or to an object that needs to be deserialized from the stream.

> I've tried creating an arraylist and populating it with the delegate
> invocation list members from a single object and that worked great as far as
[quoted text clipped - 4 lines]
> My guess is that the address of the object (target) is different to what was
> persisted.

You are right. However, the built in serialization will make sure that the
target objects of the delegate are also serialized, and it will make sure at
deserialization time that the delegates are correctly initialized.

> I'm thinking of having some kind of "naming" structure where I can pinpoint
> an object by a name for example
> "objecta.subObjecta.subSubObjectb.Method" --- but this might be a tough one
> to implement.

It seems like this is too much effort considering that the object manager
does all of that for you. Try the built in serialization. Test it out on a
few of your objects first. If you find that the space penalty is too high
try using Binary rather than Soap. If the time penalty and space penalty are
too high try factoring out the state and code of the objects that will take
part in the target methods as separate objects and serialize those instead
of the entire object.

Richard

Signature

My email address evpuneqt@zicf.bet is encrypted with ROT13 (see
www.rot13.com)

Reply to this Message

D.W. CArr - 23 Jun 2004 02:47 GMT

Most of the horror stories involve DataSets. If you are using them you should check out this KB article for a 'real' binary surrogate.

Improving DataSet Serialization and Remoting Performance
http://support.microsoft.com/default.aspx?scid=kb;en-us;829740

Damon Carr, Chief Technologist
agilefactor
http://www.agilefactor.com/

> > I want to be able to save these "object relationships" to disk though, and
> > I'm scared to use serialization. I've seen the horror stories of
[quoted text clipped - 61 lines]
>
> Richard

Reply to this Message

Matt Tavis [MSFT] - 25 Jun 2004 16:56 GMT

Hi Nate,

I would strongly suggest trying the built-in
serialization before you head down the path of building
your own. There are numerous ways of improving
performance if that becomes an issue but you should
determine that first by the letting the built-in
serialization infrastructure handle serialization for you.

Such techniques as minimizing data serialized with the
[NonSerialized] attribute, flattening object heirarchies
and performing custom serialization with the
ISerializable interface can give you improvements *if*
you need them.

Building your own infrastructure should be a *last*
resort.

Thanks.

Matt Tavis
Program Manager
Microsoft Corporation

>-----Original Message-----
>I am creating an application that is quite complex. There will be several
[quoted text clipped - 39 lines]
>
>.

Reply to this Message

Rate this thread:

Serialization of Complex objects

Free Magazines