【发布时间】：2016-04-26 04:01:04
【问题描述】：
为什么 Protocol Buffers 比 .NET 二进制序列化好这么多？我只能找到关于它有多好（在性能和大小方面）的比较，但我找不到原因。是否可以在不涉及太多细节的情况下至少部分解释？
【问题讨论】：
标签： .net serialization protocol-buffers protobuf-net
【发布时间】：2016-04-26 04:01:04
【问题描述】：
最主要的原因是二进制序列化（BinaryFormatter）比较脆弱。它对确切的类型名称等进行编码，使其无法用于归档数据，例如应用程序的文档格式。
其他原因包括性能、平台可用性等。
如果您没有任何性能问题（即消息很小），并且您只想临时存储或传递一些数据块，那么它可能会很有用。例如 - 对于在同一台计算机上的两个桌面应用程序实例之间传递小消息，它可能很有用，因为您不必为该任务添加另一个库。
【讨论】：
-
我不会说那是脆弱的，而是僵硬的。您需要加载完全相同的类型才能反序列化序列化对象，这可以被认为是一件好事。它不像其他形式的序列化那样无类型、无模式，因为您使用了不兼容的类型，字节或整个字段可能最终出现在错误的位置，“但是，它反序列化而不抱怨！”。
-
好吧，可以称之为僵化。问题是极其严格的模式是完全隐含的，因此很容易被打破。例如通过不同地拼写命名空间。如果您想在应用程序的两个实例之间传递消息（不同的版本无法通信），这种脆弱性很好，但如果您正在制作文字处理器文档格式，则不完全理想......
-
所以，这很明确：成功反序列化需要用于序列化的整个类型，包括其命名空间。您需要显式加载完全相同的类型，对您没有任何暗示。同样，根据上下文，这可能是也可能不是您想要的。无论如何，版本控制序列化类型是一个复杂的主题。例如，我想不出一个允许在消息中间插入任意字段的非文本序列化程序。使用更隐式的序列化，例如固定长度字段，将弄乱反序列化。
因为 BinaryFormatter 将类型和属性信息存储在序列化数据中，所以它更大，因此相对较慢。
ProtoBuf 将此移动到应用程序端，因此序列化器和反序列化器都必须准确地知道它们在做什么，并在代码中指定它们想要反序列化的类型和属性。
【讨论】：