views:

42

answers:

2

Right now, I'm currently serializing a class like this:

class Session
{
     String setting1;
     String setting2;
     ...etc... (other member variables)

     List<SessionAction> actionsPerformed;
}

Where SessionAction is an interface that just has one method. All implementations of the SessionAction interface have various properties describing what that specific SessionAction does.

Currently, I serialize this to a file which can be loaded again using the default .Net binary serializer. Now, I want to serialize this to a template. This template will just be the List of SessionActions serialized to a file, but upon loading it back into memory at another time, I want some properties of these SessionActions to require input from the user (which I plan to dynamically generate GUI controls on the fly depending on the property type). Right now, I'm stuck on determining the best way to do this.

Is there some way I could flag some properties so that upon using reflection, I could determine which properties need input from user? Or what are my other options? Feel free to leave comments if anything isn't clear.

A: 

If you know from start what properties will have that SessionAction, you must implement IDeserializationCallback and put to those props the attribute [NonSerialized]. When you implement the OnDeserialization method you get the new values from the user.

Timotei Dolean
+1  A: 

For info, I don't recommend using BinaryFormatter for anything that you are storing long-term; it is very brittle between versions. It is fine for short-lived messages where you know the same version will be used for serialization and deserialization.

I would recommend any of: XmlSerializer, DataContractSerializer (3.0), or for fast binary, protobuf-net; all of these are contract-based, so much more version tolerant.

Re the question; you could use things like Nullable<T> for value-types, and null for strings etc - and ask for input for those that are null? There are other routes involving things like the ShouldSerialize* pattern, but this might upset the serialization APIs.

Marc Gravell
So I guess with the nullable types, I'd have to override the serialize method for whatever serialization method I use? If I do this, how would I support two forms of serialization (one would have all the properties and the other would only have a couple)?
llamaoo7
To be honest, I'd probably have different request DTOs for the different bunches of required parameters.
Marc Gravell