Among other things, I’m using the model to create a generic history model where I store individual history states of objects by writing them to separate XML streams that I can keep in-memory. Works pretty OK this far.

However, I DO anticipate that there will be some problems when I start to cover the grounds of versioning and backwards compatibility. I’m thinking that then I’ll EITHER have to let each object have support for the multiple streaming versions as needed, or I’ll have to do as you say and disconnect the file/data storage from the object structure itself.

Also, I didn’t quite get what you meant by shared pointers.

Elling
elling.bjastad@gmail.com

Your approach could also be problematic when trying to write or read a fragment of the object structure (i.e. not starting at the root). I know because I have done the exact same thing in the past. Hooking up shared pointers is much easier when dealing with the entire object structure instead a partial object structure.

My approach is to just let each serializable object support the following two basic functions:

procedure WriteToXML(XMLNode: IXMLNode); virtual;
procedure ReadFromXML(XMLNode: IXMLNode); virtual;

Then, to stream out an object tree, I just call WriteToXML on the root object, and everything else follows automatically.

Works pretty well, I think. But I still haven’t started thinking on how to deal with changes in the object structure, and how to deal with backwards file compatibility.