如何在 protobuf-csharp-port 和 protobuf-net 之间进行选择
我最近不得不寻找最初由 Google 开发的 Protocol Buffers 库的 C# 移植。你猜怎么着，我在这里发现了两个由两个非常知名的人拥有的项目： protobuf- csharp-port，由 Jon Skeet 和 Jon Skeet 编写。 google.com/p/protobuf-net/" rel="noreferrer">protobuf-net，作者：Marc格拉维尔。我的问题很简单：我必须选择哪一个？
我非常喜欢 Marc 的解决方案，因为它在我看来更接近 C# 哲学（例如，您可以只向现有类的属性添加属性），并且看起来它可以支持 .NET 内置类型，例如 System.Guid。
我确信它们都是很棒的项目，但您有何看法？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我同意乔恩的观点；如果您在多个环境中进行编码，那么他的版本为您提供了与其他“核心”实现类似的 API。 protobuf-net 与大多数 .NET 序列化器的实现方式更加相似，因此 .NET 开发人员更熟悉（IMO）。正如 Jon 指出的那样 - 原始二进制输出应该相同，以便您可以在以后需要时使用不同的 API 重新实现。
protobuf-net 的一些要点特定于此实现：
ISerializedShouldSerialize[name]XmlType/XmlElement或DataContract/DataMember) - 表示（例如）LINQ-to-SQL 模型序列化开箱即用（只要在（*=这些功能使用 100% 有效的 protobuf 二进制文件，但可能很难从其他语言中使用）
I agree with Jon's points; if you are coding over multiple environments, then his version gives you a similar API to the other "core" implementations. protobuf-net is much more similar to how most of the .NET serializers are implemented, so is more familiar (IMO) to .NET devs. And as Jon notes - the raw binary output should be identical so you can re-implement with a different API if you need to later.
Some points re protobuf-net that are specific to this implementation:
ISerializablefor existing typesShouldSerialize[name]XmlType/XmlElementorDataContract/DataMember) - meaning (for example) that LINQ-to-SQL models serialize out-of-the-box (as long as serialization is enabled in the DBML)(*=these features use 100% valid protobuf binary, but which might be hard to consume from other languages)
您在项目中也在使用其他语言吗？如果是这样，我的 C# 端口将允许您在所有平台上编写类似的代码。如果没有，Marc 的移植可能是更惯用的 C#。 （我试图让我的代码“感觉”像普通的 C#，但设计显然是基于 Java 代码开始的，故意让那些使用 Java 的人也熟悉它。
）这是因为您可以稍后改变主意，并确信您的所有数据仍然通过其他项目有效 - 据我所知，它们应该是绝对二进制兼容的（就序列化数据而言）。
Are you using other languages in your project as well? If so, my C# port will let you write similar code on all platforms. If not, Marc's port is probably more idiomatic C# to start with. (I've tried to make my code "feel" like normal C#, but the design is clearly based on the Java code to start with, deliberately so that it's familiar to those using Java as well.)
Of course one of the beauties of this is that you can change your mind later and be confident that all your data will still be valid via the other project - they should be absolutely binary compatible (in terms of serialized data), as far as I'm aware.
根据它的 GitHub 项目站点 protobuf-csharp-port 现在已被折叠到主要的 Google Protocol Buffers 项目，因此它将是 protobuf 3 的官方 .NET 实现。然而，protobuf-net 是 最后一次更新是在 2013 年，尽管已经有一些最近在 GitHub 上提交。
According to it's GitHub project site protobuf-csharp-port has now been folded into the main Google Protocol Buffers project, so it will be the official .NET implementation of protobuf 3. protobuf-net however was last updated in 2013, although there have been some commits recently in GitHub.
我刚刚从 protobuf-csharp-port 切换到 protobuf-net，因为：
I just switched from protobuf-csharp-port to protobuf-net because:
就我而言，我想使用协议缓冲区来替换 .net 客户端和 j2ee 后端之间基于 xml 的通信模型。由于我已经在使用代码生成，因此我将采用 Jon 的实现。
对于不需要 java 互操作的项目，我会选择 Marc 的实现，特别是因为 v2 允许在没有注释的情况下工作。
In my case I want to use protocol buffers to replace an xml based communication model between a .net client and a j2ee backend. Since I'm already using code generation I'll go for Jon's implementation.
For projects not requiring java interop I'd choose Marc's implementation, especially since v2 allows working without annotations.