为什么DataContractSerializer没有实现IFormatter？

Question

我对.NET中不同形式的序列化缺乏一致性感到有点沮丧:

• DataContractSerializer - 使用新属性或旧[Serializable]属性,但序列化程序本身并不实现IFormatter,而其他一些WCF序列化程序也是如此.选择参加.

• NetDataContractSerializer - 使用新属性或旧属性,序列化程序实现IFormatter,与WCF兼容,并且是Opt IN.似乎是理想的解决方案!

• XmlSerializer - 完全独立的属性集,但是遗产,所以可以原谅这一点.

• BinaryFormatter - 实现IFormatter并使用[Serializable]属性.选择退出.

所以我的问题是,为什么DataContractSerializer至少不能与BinaryFormatter完全互换？

我真的希望他们从一开始就确定了一个很好的干净界面,这真的是在.NET框架的广阔范围内,这通常是如此有序!

编辑:只是对那些感兴趣的人(我知道这与主题的其余部分并不相关),我一直在做一些时间和大小的基准测试我认为最有可能的"在线"序列化方法:

============ 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

和尺寸:

============ 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

注意:在Core2 T9300(单线程)+ 4GB上.

Answer 1

我可以想到DataContractSerializer没有实现IFormatter的两个可能原因:

• 性能 - DCS被特别调整为尽可能快,因为WCF严重依赖于对象序列化/反序列化 - 这也是DCS不支持例如XML节点上的属性的原因之一; 尽管如此,它比XmlSerializer快10%左右

• 互操作性 - 请记住,WCF是从一开始就构建的,可以尽可能地互操作 - 不仅仅是.NET到.NET,而且可以与任何其他系统(如Java,Ruby)互操作 - 您可以这样命名; BinaryFormatter,XmlSerializer和NetDataContractSerializer都不能用于可互操作的场景 - 它们都是特定于.NET的,只能在.NET中使用和使用

这是一个常见问题 - 许多.NET开发人员只是忘记了WCF 不是 .NET特定的和仅.NET技术 - 它必须努力尽可能多地保持与许多其他可能不提供所有功能的系统的兼容性的.NET.另一个例子是WCF中的错误处理 - 不仅仅抛出.NET异常 - 这些是特定于.NET的,对Java客户端来说并不意味着什么 - 在WCF服务中使用SOAP错误!(除非你能100%肯定没有non-.NET客户端会不断打电话给你的服务)