是否有充分的理由在单平台系统上使用 .proto 文件？

Posted 2023-02-16

【中文标题】是否有充分的理由在单平台系统上使用 .proto 文件？

【英文标题】：Are there good reasons to use .proto files on a single-platform system?

【发布时间】：2012-07-18 07:26:30

【问题描述】：

我们正在开发一些通过协议缓冲区相互通信的服务。所有服务都写在 .NET 上。我预计不会将它们从 .NET 中迁移出来。我预计不会在其他平台上将相同的消息用于服务。

消息当前是用 .proto 编写的。代码生成步骤对我来说似乎是多余的。

除了跨平台兼容性（我们不关心）之外，还有什么理由用 .proto 而不是直接用 .NET 语言编写消息？

【参考方案1】：

鉴于您描述的设置（.NET-to-.NET，不太可能需要跨平台），那么我会说“不”。我们做了很多符合这一类别的事情，而且我们只是代码优先，即我们编写 C# 类型，然后使用它们。这为我们提供了对类型的完全控制和灵活性，并避免了不必要的构建/工具步骤。

确实，这实际上是 protobuf-net 的核心动机和目的：使它能够像所有其他 .NET 序列化程序一样，从常规 c# 类型工作，而无需在 DSL 中定义 (@987654322 @、DataContractSerializer、javascriptSerializer 等）。

请注意，虽然 protobuf-net 包含 .GetProto<T> 功能，但尚未在 v2 中重新实现；但是，既然跨平台预编译器已经完成并且可以正常工作，那么这是我列表中的下一个。我的观点是：如果成为需要进行跨平台等操作，那么 protobuf-net 可能能够帮助您从现有合约中生成 .proto。 p>

如果您担心自己可能在某些时候需要与其他平台互操作，请坚持使用核心 protobuf 功能集。避免添加 protobuf-net，例如：

继承 .NET 特定类型支持（DateTime、decimal 等） 参考跟踪 动态类型支持

【讨论】：

感谢马克的回复。引发这个问题的是一些真正可选的字段，它们自然会映射到 Nullable。我遇到了你的答案here。定制 xslt 让我觉得并不简单。我可能更倾向于使用默认值或标志来指示空值。你打算在 .GetProto 中支持 Nullable 吗？

@Kenn 我会尝试尽我所能支持；p 这将映射到 .proto 中的“可选”，这应该没问题。

这会使 .GetProto 与代码生成器不对称，如果我没记错的话，考虑到生成器不会将可选映射到 Nullable。

@Kenn c# 比 .proto 有更多的功能；它总是以某种方式不对称。同样，.proto 没有“数组”、“列表”和“ilist”的概念——它只是“重复”。并且 IIRC（虽然可能只启用了detectMissing），protogen 确实使用Nullable<T>，以及条件序列化指定。很确定 Nullable<T> 是 xslt 的一部分。

点了，马克。感谢您提供有关detectMissing 的提示。很遗憾我没有提出新的 *** 问题。