protobuf-net 不适合哪些场景？

Posted 2023-02-16

【中文标题】protobuf-net 不适合哪些场景？

【英文标题】：For which scenarios is protobuf-net not appropriate?

【发布时间】：2010-08-11 20:57:27

【问题描述】：

我们一直在 C# 应用程序中使用 BinarySerialization，但需要序列化的类的大小和复杂性导致序列化缓慢（反）序列化和大文件。

我们怀疑我们应该只编写自己的自定义序列化程序；但 protobuf-net 声称与标准 .Net 二进制序列化相比具有显着的速度和大小优势，并且可能比大量定制的序列化程序更容易添加到我们的应用程序中。

在花费大量时间和精力尝试让它为我们工作之前，我很想知道是否有任何交易破坏者。我们正在使用通过接口定义的属性、抽象子类的通用列表、自定义位标志枚举等等等。什么会阻止 protobuf-net 为我们工作？

【参考方案1】：

protobuf-net 尽其所能遵守核心 protobuf 规范，然后是一些（例如，它包括继承），但是：

v1 不太擅长基于接口的属性（即ICustomer 等）；我正在努力在 v2 中对此进行改进 v1 喜欢有一个无参数的构造函数（这个要求在 v2 中被取消了） 您需要告诉它如何将模型映射到字段；在 v1 中，这需要在类型上进行修饰（或者 is 有一个选项可以从名称等中推断出一些东西）；在 v2 中，这可以在外部完成 在 v1 中，标记枚举很麻烦；在 v2 中有一个选项可以将枚举作为原始整数传递，使其更适合 flgs 抽象和继承都可以，但您

必须

能够提前确定所有具体类型（将它们映射到整数键） 泛型应该没问题 锯齿状数组/嵌套列表没有中间类型是不行的 - 你可以通过在中间引入一个中间类型来解决这个问题 并非所有核心类型都有内置支持（例如，新的日期/时间偏移类型）；在“v2”中，如有必要，您可以为此引入自己的垫片 它是一个

tree

序列化器，而不是

graph

序列化器；我有一些想法，但还没有实现

如果您想要序列化的内容有一些有限的示例，我会很乐意看看它是否可能工作（我是作者）。

【讨论】：

那么... v2 怎么样了？ ;)

@Joel - 嗯；我已经被新的“聊天”系统束缚住了，以至于我已经好几个星期没看它了；我需要找时间来完成它。它真的如此接近完成（估计大约 95%）。

你的意思是如果两个对象在一个字段中持有对同一个对象的引用就会有问题吗？

【参考方案2】：

当您必须与现有软件/现有标准进行交互时，这是不合适的。例如，您不能使用它与 SMTP 服务器进行通信。

【参考方案3】：

请在blog 上阅读此关于 protobuf-net 的信息，以便引用

有什么问题？ 在大多数情况下，就是这样。 WCF 将使用 protobuf-net 来处理任何合适的 对象（数据合同等）。请注意，这是一个比 但是，按操作控制（您始终可以将界面拆分为 当然，不同的端点）。 此外，protobuf-net 确实有一些细微的差别（尤其是关于空 对象），所以运行你的单元测试等。 请注意，它仅适用于全脂 WCF；它不会帮助 Silverlight 等，因为 它缺少扩展功能——但这在这里并不新鲜。 最后，WCF 中的解析器很痛苦，AFAIK 想要完整的组装细节 包括版本号；因此，当您获得新版本时，还需要维护一件事。 如果有人知道如何解决这个问题？

【讨论】：

那句话主要是关于 WCF 插件 - protobuf-net 的一小部分。

啊哈……好吧，你得票了！ ;) 很好的一个马克....必须研究这个 protobuf-net...因为我一直想研究一个项目并因为生活等其他事情一直把它放在次要位置！ :P