DataContract vs. XmlType

Question

As part of trying to learn WCF, I am reading up on serialization. I am struggling to understand how I can control serialization in .NET 3.5. For instance, I have a simple class with a few public properties. By adding the DataContract attribute to that class, I can for instance control the namespace and the name of the class as it is serialized.

On the other hand, I could add the Serializable attribute (probably not even necessary) and an XmlType attribute, which also allows me to control the namespace and the name that is used for serializing the class.

I implemented both approaches and use the class in a ServiceContract as part of an interface call. I then use a Http analyzer to see how the various objects are serizalized and I noticed that the XmlType did not influence the xml in the http at all.

I have been trying to understand this all day. What am I missing?

Update: I do understand the difference between the two and why they are there. I just don't understand why I cannot influence the generated xml with XmlType or (just tried it XmlRoot).

Basically, you can control all details of the serialization by implementing IXmlSerializable, except the namespaces and the name of the top level element. For that, I was assuming that you would need the XmlType or XmlRoot attribute. Was I wrong?

Answer 1

See XmlSerializer vs DataContractSerializer: Serialization in Wcf.

Edit:

See Customize your .NET object XML serialization with .NET XML attributes. Get your data to serialize into the form you want first. Then put the XmlSerializerFormat attribute.

[ServiceContract]
[XmlSerializerFormat]
public interface MyService
{
 [OperationContract]
 [XmlSerializerFormat]
 void MyMethod();
}

Answer 2

The main point of the DataContractSerializer is to not control the details of serialization. Instead, the idea is to serialize your data into a form that can be consumed by the largest number of clients.

Instead of being concerned with the details of the schema, one defines a data contract in terms of the data members to be sent and received. It is a very abstract description of the data. It is serialized into a very simple format that reflects the abstract description.

The XML Serializer should be used only where you absolutely require control over the details of the XML to be serialized or deserialized. When you don't need that much control, stick with the Data Contract Serializer.

Answer 3

Well, there are lots of comparisons out there on DataContractSerializer vs. XmlSerializer.

I guess the main points in my opinion are:

• DataContract is "opt-in" - you need to explicitly add a [DataMember] attribute to any field or property (public, private, internal or whatever) to serialize - if you don't have, it won't be in there. The XmlSerializer will just serialize all public properties

• DataContract allows you to specify a specific order of the data elements - XmlSerializer is just using the order in which they appear in your source code

• XmlSerializer requires a public, parameter-less constructor for your class

In simple examples, these advantages of the DataContractSerializer might not seem like much, really - but it can be a distinct advantage in larger scale apps if your data object do not have to have a public parameter-less constructor, and that you do not have to "artificially" surface elements as public properties just to include them in serialization.

Marc

Answer 4

Point of clarification: The [Serializable] attribute has nothing to do with XmlSerialization. The [Serializable] attribute has to do with Runtime.Serialization. Confusing, yes.

There are too many serializers in .NET.