我对.NET中不同形式的序列化缺乏一致性感到有点沮丧：
DataContractSerializer - 使用新属性或旧的[Serializable]属性，但序列化程序本身并不实现IFormatter，而其他一些WCF序列化程序也是如此。选择加入。
NetDataContractSerializer - 使用新属性或旧属性，序列化程序实现IFormatter，与WCF兼容，并且是Opt IN。似乎是理想的解决方案！
XmlSerializer - 完全独立的属性集，但是遗留下来，所以可以原谅。
BinaryFormatter - 实现IFormatter并使用[Serializable]属性。选择退出。
所以我的问题是，为什么DataContractSerializer至少不能与BinaryFormatter完全互换？
我真的希望他们从一开始就确定了一个很好的干净界面，这真的是在.NET框架的扩展中，这通常是如此有序！
编辑：对于那些感兴趣的人（我知道这与主题的其余部分并不相关），我一直在做一些时间和大小的基准测试，我认为最有可能“在 - 上 - wire“序列化方法：
============ 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上。
答案 0 :(得分：5)
我可以想到DataContractSerializer没有实现IFormatter的两个可能原因：
性能 - DCS被特别调整为尽可能快，因为WCF严重且经常地依赖于对象序列化/反序列化 - 这是DCS不支持例如DCS的原因之一。 XML节点上的属性;尽管如此，它比XmlSerializer
互操作性 - 请记住，WCF是从一开始就构建的，可以尽可能地互操作 - 不仅仅是.NET到.NET，而且可以与任何其他系统（如Java，Ruby， - 你说出来的; BinaryFormatter，XmlSerializer和NetDataContractSerializer都不能用于可互操作的场景 - 它们都是.NET专用的，只能在.NET中使用和使用
这是一个常见问题 - 许多.NET开发人员只是忘记了WCF 不特定于.NET和仅.NET技术 - 它必须努力尽可能多地保持兼容性其他系统可能不提供.NET的所有功能。另一个例子是WCF中的错误处理 - 不仅仅抛出.NET异常 - 这些是特定于.NET的，并不代表Java客户端 - 在WCF服务中使用SOAP错误！ （除非您100％确定没有非.NET客户端永远致电您的服务）
答案 1 :(得分：1)
DataContract序列化使用 opt-in 策略，您必须明确标记成员以进行序列化，默认情况下不是序列化成员。使用[Serializable]属性进行序列化使用选择退出策略，其中[Serializable]对象的所有成员默认为序列化，除非标记为[NonSerialized]。
这是为了通过向数据协定对象添加字段或属性来防止意外修改数据合同。