Having DataContractSerializer serialize the same class in two different ways?

Question

I'm using the DataContractSerializer to serialize an objects properties and fields marked with DataMember attributes to xml.

Now a have another use case for the same class, where I need to serialize other properties and other fields.

Are there a way to add "another DataMemberAttribute" that can be used for my other serialization scenario?

Answer 1

No, basically.

If you want to use the existing DataContractSerializer, you'll have to maintain a second version of the DTO class and convert the data between them.

Options if you are writing your own serialization code:

• declare your own [DataMember]-style attribute(s) and interpret them at runtime in your own serialization code
• use a "buddy class"
• use external metadata (such as a file)
• use code-based configuration (i.e. via a DSL)

In reality, I expect the first will be the simplest choice.

Answer 2

There is a way to do it, but it's an ugly hack.

The DataContractSerializer can serialize objects that implement the IXmlSerializable interface. You could implement the interface and create your own ReadXml(XmlReader reader) and WriteXml(XmlWriter writer) methods that could serialize the object in different ways.

Note that you'd have to have a flag embedded within the class itself to determine which way to serialize the object. (There's no way to tell the DataContractSerializer which mode to use, so the flag has to be contained in the object itself.)

A second version of the DTO class, as @Marc suggests, would be much cleaner.

Answer 3

In a similar scenario in the past, we've taken an Object Oriented approach, and created a new class that extends from the main class. To help you achieve inhertience with the DataContractSerializer, check out KnownTypeAttribute

In one of your comments to your question,

If the same class is implementing multiple interfaces, certain data elements may be relevant to only one of the interfaces.

If that is the case in your scenario, then perhaps your Data Service Contracts should be exposing just the Interfaces, and not the Class?

For example, if you have a class like:

[DataContract]
public class DataObject : IRed, IBlue

then rather than have your operation contract expose DataObject, you have two operation contracts one for IRed and one for IBlue. This eliminates the need for custom serialization code.