.net - 为什么 DataContractSerializer 不实现 IFormatter？

Question

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

• DataContractSerializer - 使用新属性或旧的 [Serializable] 属性，但序列化程序本身并不像其他一些 WCF 序列化程序那样实现 IFormatter。选择加入。

• NetDataContractSerializer - 使用新属性或旧属性，序列化程序实现 IFormatter，与 WCF 兼容，并且是 Opt IN。看起来是理想的解决方案!

• XmlSerializer - 完全独立的属性集，但是是遗留的，因此可以原谅这一点。

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

所以我的问题是，为什么 DataContractSerializer 不能与 BinaryFormatter 保持至少相当的可互换性？

我真的希望他们从一开始就为此选择一个漂亮干净的界面，这对于通常如此有序的 .NET 框架来说确实是一种耻辱!

编辑:对于那些感兴趣的人(我知道这与主题的其余部分并不真正相关)，我一直在对我认为最有可能的“on-the-”进行时间和规模基准测试线”序列化方法:

============ 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% 确定没有非 .NET 客户端永远调用您的服务)