We have a rather large graph of objects that needs to be serialized and deserialized in many different ways (modes). In some modes, we want some properties to be deserialized, and in some not. In future modes, it is also possible that there are more options for properties than yes or no. The problem is how we implement these modes.
Approach A (use the deserialization constructor and ISerializable.GetObjectData):
If each graph object serializes itself using the deserialization constructor, we get many switches for all the various deserialization modes. The advantage of this approach is that the whole deserialization logic is in one place, and if we add new properties, we just need to change the ISerializable.GetObjectData and deserialization constructor. Another advantage is that the object can take into account internal states that can be published publicly. The most important drawback is that we, in fact, should be aware of all possible serialization modes. If we need a new mode, we need to change the data objects.
Approach B (Deserialization Factory Classes / Methods):
Another approach would be to have some sort of Deserialization Factory Classes / Methods sorted for each mode that does serialization and deserialization from the outside (like GraphSerializer.SerializeObjectTypeX (ObjectTypeX objectToSerialze). The advantage is that whenever we want a new mode we just add a new one the Factory Class / Method class, and our Dataobject does not get cluttered with all the serialization modes introduced.The main disadvantage here is that I would have to write the same serialization code again and again for all different modes If the two modes are different I only have one or two properties, but I will have to implement the full logic again for the entire graph.When I add a new property to the data object, I need to update all Factory classes.
, IMHO. .NET? , , ?