Protocol Buffer 有多快或多轻？
.NET 的 Protocol Buffer 会比 Remoting（SerializationFormat.Binary）更轻量/更快吗？ 在语言/框架方面会提供一流的支持吗？ 即它是否像远程处理/Web服务一样透明地处理？
Is Protocol Buffer for .NET gonna be lightweight/faster than Remoting(the SerializationFormat.Binary)? Will there be a first class support for it in language/framework terms? i.e. is it handled transparently like with Remoting/WebServices?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我非常怀疑它是否会有直接的语言支持，甚至框架支持——这种事情可以通过第三方库完美地处理。
我自己的 Java 代码端口是显式的 - 您必须调用方法序列化/反序列化。 （有 RPC 存根会自动序列化/反序列化，但还没有 RPC 实现。）
Marc Gravell 的项目 非常适合 WCF - 据我所知，您只需要告诉它（一次）使用协议缓冲区进行序列化，其余的都是透明的。
就速度而言，您应该查看 Marc Gravell 的基准页面。 我的代码往往比他的代码稍快，但两者都比框架中的其他序列化/反序列化选项快得多。 应该指出的是，协议缓冲区也受到更多限制 - 它们不会尝试序列化任意类型，而只会序列化支持的类型。 将来我们将尝试以可移植的方式（作为它们自己的协议缓冲区消息）支持更多常见数据类型（十进制、日期时间等）。
I very much doubt that it will ever have direct language support or even framework support - it's the kind of thing which is handled perfectly well with 3rd party libraries.
My own port of the Java code is explicit - you have to call methods to serialize/deserialize. (There are RPC stubs which will automatically serialize/deserialize, but no RPC implementation yet.)
Marc Gravell's project fits in very nicely with WCF though - as far as I'm aware, you just need to tell it (once) to use protocol buffers for serialization, and the rest is transparent.
In terms of speed, you should look at Marc Gravell's benchmark page. My code tends to be slightly faster than his, but both are much, much faster than the other serialization/deserialization options in the framework. It should be pointed out that protocol buffers are much more limited as well - they don't try to serialize arbitrary types, only the supported ones. We're going to try to support more of the common data types (decimal, DateTime etc) in a portable way (as their own protocol buffer messages) in future.
此页面上提供了一些性能和大小指标。 我现在还没有乔恩的统计数据，只是因为页面有点旧（乔恩：我们必须解决这个问题！）。
重新透明； protobuf-net 可以通过合约hook到WCF； 请注意，它也可以通过 basic-http 与 MTOM 很好地配合。 但这不适用于 Silverlight，因为 Silverlight 缺少注入点。 如果您使用 svcutil，您还需要向类添加属性（通过分部类）。
Re BinaryFormatter（远程处理）； 是的，这得到了充分的支持； 您可以简单地通过一个简单的
ISerialized实现来完成此操作（即只需使用相同的参数调用Serializer方法）。 如果您使用 protogen 创建类，那么它可以为您完成：您可以通过参数在命令行中启用此功能（默认情况下不会启用 BinaryFormatter） > 不适用于所有框架 [CF 等]）。请注意，对于本地远程处理 (IPC) 上的非常小的对象（单个实例等），原始 BinaryFormatter 性能实际上更好 - 但对于重要的图形或远程链接（网络远程处理）protobuf-net可以很好地超越它。
我还应该注意到，协议缓冲区有线格式不直接支持继承； protobuf-net 可以欺骗这一点（同时保留线路兼容性），但与 XmlSerializer 一样，您需要预先声明子类。
为什么有两个版本？
我猜想是开源的乐趣；-p Jon 和我之前曾参与过联合项目，并讨论过将这两个项目合并，但事实是他们针对两种不同的场景
XmlSerializer、DataContractSerializer等相比）您正在使用 java 和 . NET 客户端，对于双方都熟悉的 API，Jon 可能是一个不错的选择。 如果您是纯 .NET，protobuf-net 具有优势 - 熟悉的 .NET 风格 API，而且：
[DataContract]和[XmlType]类通常可以在不进行任何更改的情况下使用）BinaryFormatter、XmlSerializer、WCF、DataContractSerializer) - 允许它直接作为远程处理引擎工作。 对于 Jon 的移植来说，这可能与主 java 主干有很大的差距。重新合并它们； 我认为我们都对此持开放态度，但您似乎不太可能想要这两个功能集，因为它们针对的需求如此不同。
Some performance and size metrics are on this page. I haven't got Jon's stats on there at the moment, just because the page is a little old (Jon: we must fix that!).
Re being transparent; protobuf-net can hook into WCF via the contract; note that it plays nicely with MTOM over basic-http too. This doesn't work with Silverlight, though, since Silverlight lacks the injection point. If you use svcutil, you also need to add an attribute to class (via a partial class).
Re BinaryFormatter (remoting); yes, this has full supprt; you can do this simply by a trivial
ISerializableimplementation (i.e. just call theSerializermethod with the same args). If you useprotogento create your classes, then it can do it for you: you can enable this at the command line via arguments (it isn't enabled by default asBinaryFormatterdoesn't work on all frameworks [CF, etc]).Note that for very small objects (single instances, etc) on local remoting (IPC), the raw
BinaryFormatterperformance is actually better - but for non-trivial graphs or remote links (network remoting) protobuf-net can out-perform it pretty well.I should also note that the protocol buffers wire format doesn't directly support inheritance; protobuf-net can spoof this (while retaining wire-compatibility), but like with XmlSerializer, you need to declare the sub-classes up-front.
Why are there two versions?
The joys of open source, I guess ;-p Jon and I have worked on joint projects before, and have discussed merging these two, but the fact is that they target two different scenarios:
XmlSerializer,DataContractSerializer, etc)If you are working on java and .NET clients, Jon's is probably a good choice for the familiar API on both sides. If you are pure .NET, protobuf-net has advantages - the familiar .NET style API, but also:
[DataContract]and[XmlType]classes can often be used without any changes at all)BinaryFormatter,XmlSerializer, WCF,DataContractSerializer) - allowing it to work directly as a remoting engine. This would presumably be quite a big split from the main java trunk for Jon's port.Re merging them; I think we'd both be open to it, but it seems unlikely you'd want both feature sets, since they target such different requirements.