C# 使用BinaryFormatter代替protobuf net的原因

因此，在我看到的许多基准测试中，protobuf net远远领先于BinaryFormatter： - -

这就引出了一个问题：如果protobuf net可用，为什么要使用BinaryFormatter

---

我读过一些关于BinaryFormatter存储类型元数据的内容，protobuf并没有这样做。你能给我一个示例场景，我想在其中存储类型元数据吗？

我目前正在努力使用protobuf net来序列化Dictionary类型的对象。我所读到的是这是不可能的，所以我想这是一个人们更喜欢BinaryFormatter的场景。

我已经看到了这个问题；我只是不知道在什么情况下我会选择BinaryFormatter；pI已经查看了基准测试，看起来很不公平，并且支持BinaryFormatter，因为protobuf没有实现本机引用映射，protobuffer存储引用相同的数据事件。抱歉，无法完成注释（已通过最大延迟）。测试正在序列化“100000个iden-ti-cal实例”，因此BinaryFormatter存储1个数据和100K个引用。另一方面，protobuf存储数据的全部拷贝。这个测试并不能代表protobuf的能力，因为我们永远不需要发送100K相同的记录，我将称这个测试为“不公平”。）无法比较那些序列化程序。protobuf不支持循环对象图（引用），现代趋势转向有向图仅来自非同构系统中的数据封送需求。protobuf就是为了这个而建立的，就像节俭和其他很多东西一样。BinFrmtr是一个“透明”CLR图serlzr，在许多类似集群的系统中都需要它，在这些系统中，本地CLR对象需要在集群中分布，只是为了性能，而不需要对象可移植性。但是请记住，BinFormtr非常慢，而且不必如此。有NFX Slim之类的替代方案。无论如何，BinFmter（以及类似产品）有一个强大的用例。在集群系统中，非常需要在机器之间分配负载，因为一些数据需要“移动”。有时仅仅为了移动数据而创建DTO（数据传输对象）是非常不方便的，因为许多“duck-typing”语言的支持者讨厌“经典OOP”语言——“垃圾DTO类型”的激增。在大多数情况下，本机CLR对象序列化程序允许重用已有的对象，以实现业务逻辑。在下面添加了NFX Slim Serializer的链接，这是字典使用ISerializable自定义方法存储内容和比较器的快捷方式。您可以使用BinaryFormatter，也可以使用这个（速度快10倍）：（我是作者）