Why does DataContractSerializer not implement IFormatter?

Question

I'm getting a bit frustrated by the lack of consistency within the different forms of serialization in .NET:

• DataContractSerializer - uses new attributes OR old [Serializable] attributes, but the serializer itself does not implement IFormatter where some of the other WCF serializers do. Opt IN.

• NetDataContractSerializer - uses new attributes OR old, serializer implements IFormatter, is compatible with WCF, and is Opt IN. Seems like the ideal solution!

• XmlSerializer - totally independant set of attributes, but is legacy so can forgive this.

• BinaryFormatter - implements IFormatter and uses the [Serializable] attributes. Opt OUT.

So my question is, why does DataContractSerializer not stay at least fairly interchangable with BinaryFormatter?

I really wish they'd settled on a nice clean interface for this from the start, its a shame really in the expanse of the .NET framework which is usually so ordered!

Edit: Just for those who are interested (I know this isnt really relevant to the rest of the topic), I've been doing some both time and size benchmarking of what I perceive as the most likely "on-the-wire" serialization methods:

============ Serialization ============

Protobuf     x158,194 39,549 per/sec  1.00
OldFieldbase  x58,191 14,548 per/sec  2.72
Fieldbase     x57,445 14,361 per/sec  2.75
DataContract  x54,611 13,653 per/sec  2.90
Binary        x29,466  7,367 per/sec  5.37
Net           x28,170  7,043 per/sec  5.62
Json          x10,605  2,651 per/sec 14.92

And sizes:

============ SerializationSizes ============

Protobuffers  209 bytes 1.00
Fieldbase     246 bytes 1.18
OldFieldbase  248 bytes 1.19
Json          728 bytes 3.48
DataContract 1227 bytes 5.87
Net          1658 bytes 7.93
Binary       1826 bytes 8.74

NOTE: On a Core2 T9300 (single threaded) + 4GB.

Answer 1

DataContract serialization uses an opt-in strategy, where you have to explicitly mark members for serialization, and the default is not to serialize a member. Serialization using the [Serializable] attribute uses an opt-out strategy, where all members of the [Serializable] object are serialized by default unless marked as [NonSerialized].

This is intentional in order to prevent accidental modifications of data contracts by adding fields or properties to the data contract objects.

Answer 2

I can think of two possible reasons why DataContractSerializer doesn't implement IFormatter:

• performance - DCS was tweaked specifically to be as fast as possible, since WCF relies heavily and frequently on object serialization/deserialization - that's one of the reasons that the DCS doesn't support e.g. attributes on XML nodes either; with all that, it's about 10% faster than XmlSerializer

• interoperability - remember, WCF was built from the get-go to be as interoperable as it could possibly be - not just .NET to .NET, but interoperable with any number of other systems, like Java, Ruby, - you name it; neither the BinaryFormatter, nor the XmlSerializer, nor the NetDataContractSerializer can be used in an interoperable scenario - they're all .NET specific and only available and useable from .NET

This is a common issue - many .NET developers just simply forget that WCF is not a .NET specific and .NET only technology - it has to strive to maintain as much compatibility as possible with lots of other systems that might not offer all the features of .NET. Another case in point is the error handling in WCF - don't just throw .NET exceptions - those are .NET specific, and don't mean a thing to a Java client - use SOAP faults in your WCF services! (unless you can be 100% sure that no non-.NET client will ever call your service)