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

我们正在开发一些通过Protocol Buffers进行通信的服务。所有的服务都是用.NET编写的。我没有预见到将它们从.NET迁移出去。我没有预见到在其他平台上使用与服务相同的消息。在单一平台系统上使用.proto文件是否有很好的理由？

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

除了跨平台兼容性（这不是我们关心的），没有任何理由来写.proto而不是直接在.NET语言的消息？

2012-07-18 Watsontap

鉴于你所描述的设置（.NET到.NET，不太可能需要跨平台），那么我会说“不”。我们做了一个很多的事情，我们只是在代码优先，即我们编写C＃类型，并使用它们。这使我们能够对这些类型进行全面的控制和灵活性，并避免不必要的构建/加工步骤。实际上，这实际上是protobuf-net的核心动机 - 为了和目的：它能够像常规的c＃类型一样工作，而不需要在DSL中定义，就像所有其他的.NET序列化器一样（XmlSerializer ，DataContractSerializer,JavaScriptSerializer等）。

注意的是，虽然protobuf网包括.GetProto<T>功能，这尚未在V2重新实现;但是，现在我的列表中已经完成了跨平台预编译器的工作。在这里我想说的是：它是可能的，如果有变得做跨平台等的要求，然后protobuf网或许能够帮助生成从现有的合同为您.proto。

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

继承
.NET特定型支撑（DateTime，decimal等）
参考跟踪
动态型支撑

来源

2012-07-18 07:36:06

感谢您的回复Marc。引发这个问题的是一些真正的可选字段，它们自然会映射到可空的。我跑过你的答案[这里]（http://stackoverflow.com/questions/4763875/does-protobuf-net-support-nullable-types）。定制xslt让我觉得不简单。我可能会更倾向于使用默认值或标志来指示空值。您是否打算在.GetProto 中支持可空？ – Watsontap 2012-07-18 08:17:23

@Kenn我会*尝试*支持任何我可以; p这将映射到.proto中的“可选”，这应该很好。 – 2012-07-18 08:19:32

这将使.GetProto 不对称的代码生成器，如果我没有记错的话，考虑到发电机不映射到可选可空。 – Watsontap 2012-07-18 08:33:23

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

回答

相关问题