I am in charge with updating a software product that is made up of two components the Controller process and the UI process. The Controller and the UI communicate via XML messages. Furthermore, the Controller is built on top of a shared library that implements a number of business flows.
For builing the messages for Controller-UI communication, somebody decided to use .NET built-in serialization and deserialization and therefore created class types annotated with attributes that control serialization (XmlElement, XmlAttribute, etc) for each message, serializing it and deserializing it by using the default XML serializer.
For the first couple of controllers, this was fine. But now, while some of the messages can be reused, the other cannot. They will accomplish the similar functions but are structurally incompatible with the information we need them to contain.
Because this decision was made we are stuck with data-types that cannot model the data we need, and cannot be changed because they would break the other controllers. At the same time we need the functionality and messaging sequences implemented in the shared library.
I need a way out of this conundrum, one that has the smallest technical cost in relation to changing the other controllers, I need a sort of “structural polymorphism” for these types, where the type is the same but its internal structure different.
Perhaps these messages can be changed to ‘object’ data types, but in that case… I need a way to control from the outside of the shared library the casting that gets made inside the shared library.
How do I approach this, I am not experienced enough to find a clean refactoring for this? I feel stuck.
We are using .NET 4.5
The default XML Serializer is quite flexible. Ignores (by default) what doesn’t know (that’s it information on the xml file/stream for which there is no member variable), and what it knows and it is not present (in the xml file/stream), it gives defaults. So, a very dirty way is just to add what you need where you need it. It will work. It will not be pretty.
If you want to have a bit more control, you can implement IXmlSerializable and override WriteXml and ReadXml methods to write or read only what is needed from/to the xml file/stream
I need a way out of this conundrum, one that has the smallest technical cost in relation to changing the other controllers, I need a sort of “structural polymorphism” for these types, where the type is the same but its internal structure different.
You mean like basic inheritance? I’m not sure I see the trouble here. If you have a common set of functionality, then define an interface (or abstract base class) for that functionality. If you have different implementations of that functionality (including internally serialized members) then simply make different implementations of that interface.
You will likely need to use KnownType or other attributes to make sure that the serializer knows about the implementation types. And you may find that using a different serialization medium (json, binary) may make your life easier. But from a design approach, this seems straightforward.
3