Differences and Usage Analysis Between XmlSerializer, DataContractSerializer, and BinaryFormatter

Differences and Usage Analysis Between XmlSerializer, DataContractSerializer, and BinaryFormatter

. NET provides many methods for serializing objects. Only by knowing the differences between them can we better determine which serialization method to use and use correctly. This article analyzes the three serialization methods in the title from the following aspects.

• Range:Property Or Field Or Both
• Visibility:Public or Private Or All
• Accessibility:Readonly Property
• Callback:The callbacks include OnSerializing, OnSerialized, OnDeserializing, and OnDeserialized.
• Objects that contain circular references
• Objects containing Dictionary
• Unordered read (XML)
• Custom serialization result.
• There are no Attribute requirements for the serialized class. Sometimes the serialized object is located in a third-party library and the source code cannot be modified. If you want to serialize such an object, you cannot use Serializer with Attribute.

First, sort out the results and analyze the results: the code can be downloaded from here, and the written test may not be comprehensive. If there are any errors, please point out that it would be a mistake. However, I believe this table will not be worse if there is an article by mistake (Google top 1.

	XmlSerializer	DataContractSerializer	BinaryFormatter
Range	Both	Both	Field Only
Visibility	Public Only	All	All
Read-only attribute	Not Supported	Yes, but Attribute must be added.	N/
Callback support	Not Supported	Supported	Supported
Loop reference	Not Supported	Yes, but Attribute must be added.	Supported
Dictionary	Not Supported	Supported, in proprietary format	Supported
Unordered read	Supported	Not Supported	Not Supported
Custom format	Supported. Attribute must be added.	Xml Attribute is not supported.	Interface
Attribute requirements	Not Required	Not Required	Must have Serializable

There are several points to explain.

Performance? Size?

In the test cases I wrote, the performance and size of these serializers are basically an order of magnitude for simple objects, nested objects, or repeated reference objects in arrays. The functional differences between them are much larger than their performance differences. In this case, the decision on which method to use should depend on the function and its constraints, rather than the performance. If you care about performance, you should use a third-party library, such as Google's protobuf-net. Protobuf-net is superior to other three in terms of performance, serialization result size, and compatibility. Of course, not human readable.

Attribute requirements

Many similar articles claim that both XmlSerializer and DataContractSerializer require the corresponding Attribute to be added to the class. But this is not the case. Attribute is necessary only when you want to change the default serialization result.

The most common error is to add Serializable Attribute to the class used by XmlSerializer. This Attribute is actually used for BinaryFormatter and SoapFormatter. It is generally used for Remoting and Messaging.

Unordered read

Unordered reading means that the order of Xml nodes is not required during Deserialize. Xml itself is a markup language with declaration. Most Xml-based network protocols do not require the sequence of Xml nodes. For example, common RSS, ATOM, and opd5.

DataContractSerializer used by WCF requires that the Xml node sequence be either strictly specified or alphabetically arranged. performance may be considered. However, the positioning of WCF is the root cause that DataContractSerializer strictly requires the Xml node sequence. WCF itself is used for communication. Its positioning of serialization is only a means of message transmission, and there is no bad definition of the Message format, in addition, the caller's code can be generated through the WSDL, which naturally does not cause resolution problems. Therefore, reading in disorder is determined by the function settings.

XmlSerializer can be used as an Object Xml Mapping tool in my opinion. Of course, we should try our best to support all Xml standards.

Custom support

Both XmlSerializer and DataContractSerializer support the IXmlSerializer interface. Using this interface, DataContractSerializer can even support Attribute. However, this is not actually the serialization mechanism of DataContractSerializer. In addition, it is not feasible in actual projects. Therefore, in the preceding table, Mark DataContractSerializer as not supporting Xml Attribute.

Some common interfaces, such as ISerializable and IDeserializationCallback, are used for BinaryFormatter to support custom serialization. Here I am surprised that OnDeserialized Attribute has been supported for BinaryFormatter. Why is there such an interface to provide similar functions.

Some small details

There are still some small and interesting differences between the two Xml serialization methods. I tried to guess the reason for this difference, but I did not think about it. Maybe it is a design concept that Microsoft employees do not know, maybe it's just easy to write code.

Summary

Based on the above objective results, I believe you have made your own judgment. My personal opinion is that DataContractSerializable is used in the places where it should be used. If it is not for WCF, do not use it. Its serialization result has something exclusive to Microsoft. XmlSerializer is the best choice for loose Xml interface data from the network. If you want to completely Save the object (data and status) without being viewed by others. Use BinaryFormatter. If you have high requirements on performance or data size, you can use them all. Use protobuff.

Supplement

This information is an experience, but it is definitely not suitable for joint interviews or written questions.