XML Serialization – Handling Complex Situations

design-patternsserialization

I'm considering passing xml back and forth for error messages but each error has different scenarios.

one situation at hand is passing diffed text comparison while others are as simple as passing a text message.

What kind of serialization/deserialization strategy could I use for such a scenario?

The main issue with a scenario like this is that the object is different from case to case and there needs to be a mechanism for identifying what type it is.

Serializing xml is pretty straight forward:

Three sloppy ideas pop into my mind from the start:

  1. Make some super class that contains every possibility of contained
    types.
  2. Make some mechanism for reading the xml first to identify
    what's in it.
  3. Use option 2 and convert the inner body xml to an
    object.

A more elegant approach would be to implement some kind of Action pattern, where, once the object was identified you could create the proper action to take with it.

Some ideas consist of the Action/Executor pattern or IoC:

Here is an example pattern idea that runs parrallel to what I'm thinking:

Not for data persistence but for error handling by the client:
The client decides how to handle the error once received based on the Action from a base library that takes place after deserialization.

my considered xml format would be something like this:

diff error:

<errorMessage>
<header>The header is not correct</header>
<body>

<diffErrorArray>
<diffItem message="NoChange">
<customMessage>Correct</customMessage>
<source>HeaderColumn1</source>
<destination>HeaderColumn1</destination>
</diffItem>

<diffItem message="Replace">
<customMessage>Changed</customMessage>
<source>HeaderColumn1</source>
<destination>Header_Column_1</destination>
</diffItem>

<diffItem message="AddDestination">
<customMessage>Unknown</customMessage>
<source></source>
<destination>Header_Column_1</destination>
</diffItem>

<diffItem message="DeleteSource">
<customMessage>Missing</customMessage>
<source>HeaderColumn2</source>
<destination></destination>
</diffItem>

</diffErrorArray>

</body>
</errorMessage>

string error:

<errorMessage>
<header>Bad news</header>
<body>
<stringErrorMessage>Something really bad happened.</stringErrorMessage>
<body>
</errorMessage>

Best Answer

Xml deserialization - at least in case of C# (you're not referring to it directly, but your links indicate it as your language of choice) - has type recognition built in. Why not make use of that?

See https://stackoverflow.com/questions/775647/how-do-i-deserialize-xml-without-knowing-the-type-beforehand for more details.

1: Make some super class that contains every possibility of contained types.

As demonstrated in the question I linked to above, all it takes is creating some common base class for your errorMessage objects. Then you need to use XmlInclude.

So the super class would only have to "contain every possibility" in the sense of knowing about all its subtypes (but not their implementation details). It's still all nice and neat in terms of OOP.

Note that if you feel that .NET serialization is too limiting, there's always more sophisticated alternatives such as SharpSerializer - better suited for polymorphic scenarios.

Again, this is not a language-agnostic suggestion, but if you used another programming language, the advice still applies: you can look for a good open-source library.

2: Make some mechanism for reading the xml first to identify what's in it.

You could also use reflection and retrieve the type in run-time (as Kirtan suggested) by the name of the root element, or some attribute of the root element.

Another option would be to create, or generate, XSD schemas for your errorMessage items, then use these schemas to validate the incoming messages - thus establishing their "type identity".

One advantage of this admittedly a bit more troublesome solution is that if the incoming xml was somehow broken, xsd validation could tell you exactly where and why (eg. some unexpected, unrecognized element), you don't have to handle this "manually".

Then there's dynamic typing and yet another interesting approach:

https://stackoverflow.com/a/13705918/168719

A more elegant approach would be to implement some kind of Action pattern, where, once the object was identified you could create the proper action to take with it.

That's what takes place after you deserialize the message, doesn't it?

With regard to this, I don't think one could come up with suggestions superior to what you have already found in this thread: https://stackoverflow.com/questions/298976/is-there-a-better-alternative-than-this-to-switch-on-type

I hope this gives you some inspiration. If not, the principle I go by is: when it's awfully hard to solve a problem, most likely the problem itself is badly posed from the very beginning. So if you are stuck, maybe it's time to step back and redesign. I don't know broader context, so I have no way of knowing how possible it is in your case.

Related Topic