protobuf-net中是否存在可扩展性机制来控制原始序列化？

Question

我们正在使用protobuf-net来序列化和反序列化深层对象图。其中一些成员 图形在许多图形中反复重复，就像多个对象的多对一关系一样。例如， Sale 对象将是图形及其 Store 成员 （可能是一个子图本身）将只是10个可能的商店中的一个，因此它将是 在许多消息中反复重复（ Sale 图表）。

如果我们可以以某种方式缓存这些对象的序列化，我们可以获得明显的性能优势。理想情况下，我们想告诉 RuntimeModel 某些类型 - 在这种情况下， Store - 应该通过可扩展点来处理，就像代理一样，但是我们能够提供原始序列化字节。

我们的一个限制是生成的消息应该仍然是protobuf-net兼容的 命令可以被其他平台（比如Python）中的客户端直接解析，而不需要这些“钩子” （为Python客户端进行螺丝性能优化！）。

我们看了代理人，但它看起来无论代理人产生什么（在我们的情况下会这样做 以某种方式 byte []数组）（正如您所期望的那样）仍然被序列化为其类型（即 byte [] array）因此与Python客户端所期望的 Store 对象不兼容。

我们还查看了Extensions，即使我们以某种方式攻击了缓存的序列化 Store 额外的字段，我们将回到Python客户端。

我们可能会为此方案使用任何其他可扩展性机制吗？

Answer 1

哦，有趣的是。实际上，python需求会破坏我去所说的内容（引用跟踪）。您可以做的是将每个首先序列化为byte[]（通过MemoryStream），然后将这些数据包含为{{1成员（byte[]和原始对象之间没有区别 - 外部客户端不会注意到任何差异），但是在大多数情况下，这种想法不会比仅保留对象模型“按原样”并多次序列化一些节点（序列化不是很慢）。

但是坦率地说，我会考虑以不同的方式存储它 - 所以不是将存储存储为子节点，而是将它们作为顶级节点唯一存储，并且只存储一些唯一标识符作为查找（不是子对象本身）。但是，这会改变布局。

不，没有内置任何东西来支持这一点，我不确定这是支持的关键场景。