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?
DataContractSerializer can able to serialize types that implements Idictionary whereas XML serializer not. DataContractSerializer serializes all members which are marked with [DataMember] attribute even if member is marked private. XML serializer serialize only public members.
The following types built into the . NET Framework can all be serialized and are considered to be primitive types: Byte, SByte, Int16, Int32, Int64, UInt16, UInt32, UInt64, Single, Double, Boolean, Char, Decimal, Object, and String.
The process forms a sequence of bytes into a logical object; this is called an encoding process. At runtime when WCF receives the logical message, it transforms them back into corresponding . Net objects. This process is called serialization.
Data Contracts can be defined as follows: It describes the external format of data ed to and from service operations. It defines the structure and types of data exchanged in service messages. It maps a CLR type to an XML Schema. It defines how data types are serialized and deserialized.
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.
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();
}
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With