对于哪些情况，protobuf-net不合适？

Question

我们一直在使用BinarySerialization和我们的C＃app，但是需要序列化的类的大小和复杂性导致了sloooooow（de）序列化和大文件。

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

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

Answer 1

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

• v1不是很擅长基于接口的属性（即ICustomer等）;我正在努力改进v2
• v1喜欢那里有一个无参数构造函数（此要求在v2中解除）
• 你需要告诉它如何将模型映射到字段;在v1中，这需要在类型上进行修饰（或者是一个选项，用于从名称等中推断出一些东西）;在v2中，这可以在外部完成
• 在v1中，标志枚举是一种痛苦;在v2中，有一个选项可以将枚举作为原始整数传递，使其更适合于falgs
• 摘要和继承很好，但你必须能够提前确定所有具体类型（将它们映射到整数键）
• 泛型应该没问题
• 锯齿状数组/嵌套列表没有中间类型不正常 - 您可以通过在中间引入中间类型来填充这个
• 并非所有核心类型都具有内置支持（例如，新的日期/时间偏移类型）;在“v2”中，如果需要，您可以为此引入自己的垫片
• 它是树序列化程序，而不是图形序列化程序;我有一些想法，但还没有实现

如果您想要序列化的内容有限，我很乐意看看它是否可行（我是作者）。

Answer 2

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

Answer 3

请在此blog关于protobuf-net阅读此内容，以引用

What’s the catch?

In the most part, that’s it. WCF will use protobuf-net for any suitable 
objects (data-contracts etc). Note that this is a coarser brush than the 
per-operation control, though (you could always split the interface into 
different endpoints, of course).

Also, protobuf-net does have some subtle differences (especially regarding empty 
objects), so run your unit tests etc.

Note that it only works on the full-fat WCF; it won’t help Silverlight etc, since 
it lacks the extension features – but that isn’t new here.

Finally, the resolver in WCF is a pain, and AFAIK wants the full assembly details 
including version number; so one more thing to maintain when you get new versions. 
If anyone knows how to get around this?