2

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

2 Answers 2

Reset to default
3

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

1

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
  • The new controllers are built on the base library class. They have different data requirements, but need to reuse the messaging sequence implemented in the base library but extracting a common interface to represent any type of data hierarchy/representation is not possible. Since default serialization was used, it's dependent on a well defined message class type. So the base library has to be able to somehow lose the dependency on the type, or be able to somehow use a generic type for the message (like object) but then know what to cast it to based on the stuff defined in the controller.
    – Rire1979
    Commented Apr 13, 2014 at 17:03
  • The most flexible format for the message would have been simply the xml object format. But since at the very beginning default .NET serialization was used, the messages became fixed data types. It was possible with small adjustments to the message class to add necessary information such that several other controllers could be supported, but now that is no longer possible. So the challenge is how to support the new controller and the old controllers at the same time.
    – Rire1979
    Commented Apr 13, 2014 at 17:11
  • 1
    @Rire1979 -Eh? Sounds as though you want to Make the base library type generic and pass in the message DTO type.
    – Telastyn
    Commented Apr 13, 2014 at 21:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.