72

我最近不得不寻找最初由 Google 开发的 Protocol Buffers 库的 C# 移植。猜猜看，我在这里发现了两个非常知名的人拥有的两个项目：由Jon Skeet编写的protobuf-csharp-port和由Marc Gravell编写的protobuf-net。我的问题很简单：我必须选择哪一个？

我非常喜欢 Marc 的解决方案，因为在我看来它更接近 C# 哲学（例如，您可以只向现有类的属性添加属性），并且它看起来可以支持 .NET 内置类型，例如 System.Guid。

我相信他们两个都是非常棒的项目，但你有什么意见？

4

5 回答 5

67

我同意乔恩的观点；如果您在多个环境中进行编码，那么他的版本为您提供了与其他“核心”实现类似的 API。protobuf-net 与大多数 .NET 序列化程序的实现方式更加相似，因此对 .NET 开发人员更熟悉（IMO）。正如 Jon 所指出的 - 原始二进制输出应该是相同的，因此您可以在以后需要时使用不同的 API 重新实现。

protobuf-net 的一些要点是特定于此实现的：

  • 适用于现有类型（不仅仅是从 .proto 生成的类型）
  • 在 WCF 和 memcached 之类的东西下工作
  • 可用于实现ISerializable现有类型
  • 支持继承*和序列化回调方法
  • 支持常见的模式，如ShouldSerialize[name]
  • 适用于现有的修饰类型（XmlType/XmlElement或DataContract/ DataMember） - 意味着（例如）LINQ-to-SQL 模型开箱即用地序列化（只要在 DBML 中启用序列化）
  • 在 v2 中，适用于没有任何属性的 POCO 类型
  • 在 v2 中，适用于 .NET 1.1（不确定这是一个巨大的销售功能）和大多数其他框架（包括 monotouch - 耶！）
  • 可能（尚未实现）v2 可能支持全图*序列化（不仅仅是树序列化）

（*=这些功能使用 100% 有效的 protobuf 二进制文件，但可能很难从其他语言中使用）

于 2010-03-26T11:18:22.853 回答
46

您是否也在项目中使用其他语言？如果是这样，我的 C# 端口将允许您在所有平台上编写类似的代码。如果不是，Marc 的端口可能是更惯用的 C# 开始。（我试图让我的代码“感觉”像普通的 C#，但设计显然是基于 Java 代码开始的，故意让使用 Java 的人也熟悉它。）

当然，这样做的好处之一是您可以稍后改变主意，并确信您的所有数据在另一个项目中仍然有效——就我而言，它们应该是绝对二进制兼容的（就序列化数据而言）我知道。

于 2010-03-26T10:18:06.643 回答
9

根据它的GitHub 项目站点， protobuf-csharp-port现在已被合并到主要的 Google Protocol Buffers 项目中，因此它将成为 protobuf 3 的官方 .NET 实现。然而，protobuf-net最后一次更新是在 2013 年，尽管已经有最近在 GitHub 上的一些提交。

于 2015-07-23T10:41:02.077 回答
7

我刚刚从 protobuf-csharp-port 切换到 protobuf-net，因为：

  • protobuf-net 更像“.net”，即序列化成员的描述符而不是代码生成。
  • 如果您想编译 protobuf-csharp-port .proto 文件，您必须执行 2 步过程，即使用 protoc 编译为 .protobin，然后使用 protoGen 编译。protobuf-net 一步完成。
于 2010-06-16T12:43:19.420 回答
3

就我而言，我想使用协议缓冲区来替换 .net 客户端和 j2ee 后端之间基于 xml 的通信模型。因为我已经在使用代码生成，所以我会选择 Jon 的实现。

对于不需要 java interop 的项目，我会选择 Marc 的实现，特别是因为 v2 允许在没有注释的情况下工作。

于 2011-10-18T18:06:49.627 回答