Reputation: 17724
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?
Upvotes: 2
Views: 1726
Reputation: 7830
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.
Upvotes: 1
Reputation: 41802
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.
Upvotes: 0
Reputation: 1062780
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:
[DataMember]
-style attribute(s) and interpret them at runtime in your own serialization codeIn reality, I expect the first will be the simplest choice.
Upvotes: 2