我们正在开发一些通过协议缓冲区相互通信的服务。所有服务都写在 .NET 上。我预计不会将它们从 .NET 中迁移出来。我预计不会在其他平台上使用与服务相同的消息。
这些消息当前是用 .proto 编写的。代码生成步骤对我来说似乎是多余的。
除了跨平台兼容性（这不是我们关心的问题）之外，还有什么理由用 .proto 而不是直接用 .NET 语言编写消息？
问问题
194 次
1 回答
4
鉴于您描述的设置（.NET-to-.NET，不太可能需要跨平台），那么我会说“不”。我们做了很多符合这一类的事情，我们只是代码优先，即我们编写 C# 类型，然后使用它们。这给了我们对类型的完全控制和灵活性，并避免了不必要的构建/工具步骤。
事实上，这实际上是 protobuf-net 的核心动机和目的：它能够像所有其他 .NET 序列化程序一样，从常规 c# 类型工作而无需在 DSL 中定义（XmlSerializer、DataContractSerializer、JavaScriptSerializer等） .
请注意，虽然 protobuf-net 包含一个.GetProto<T>功能，但它尚未在 v2 中重新实现；但是，既然跨平台预编译器已经完成并且可以正常工作，那么这是我列表中的下一个。我的观点是：如果需要跨平台等，那么protobuf-net 可能能够帮助您从现有合约中生成 .proto。
如果您担心在某些时候可能需要与其他平台互操作，请坚持使用核心 protobuf 功能集。避免添加 protobuf-net，例如：
- 遗产
- .NET 特定类型支持（
DateTime,decimal等） - 参考跟踪
- 动态类型支持
于 2012-07-18T07:36:06.257 回答