3

We're developing a few services that communicate with each other via Protocol Buffers. All the services are written on .NET. I don’t foresee migrating them off of .NET. I don’t foresee using the same messages with services on other platforms.

The messages are currently written in .proto. The code generation step seems superfluous to me.

Aside from cross-platform compatibility (which is not a concern to us), is there any reason to write messages in .proto instead of directly in a .NET language?

Watsontap
  • 152
  • 8

1 Answers1

4

Given the setup you describe (.NET-to-.NET, unlikely to need cross-platform), then I would say "no". We do a lot of things that meet this category, and we just work code-first, i.e. we write the C# types, and just use them. This gives us total control and flexibility over the types, and avoids unnecessary build/tooling steps.

Indeed, that was actually the core motivation-for, and purpose-of protobuf-net: for it to be able to work from regular c# types without requiring definition in a DSL, like all other .NET serializers do (XmlSerializer, DataContractSerializer, JavaScriptSerializer, etc).

Note that while protobuf-net includes a .GetProto<T> feature, this has not yet been re-implemented in v2; however, that is next on my list now that the cross-platform precompiler is done and working. My point here is: it is likely that if there becomes a requirement to do cross-platform etc, then protobuf-net may be able to help generate the .proto for you from the existing contracts.

If you are concerned that you might at some point need interop to other platforms, stick to the core protobuf feature set. Avoid protobuf-net additions, like:

  • inheritance
  • .NET-specific type support (DateTime, decimal, etc)
  • reference tracking
  • dynamic type support
Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • Thanks for the reply Marc. What sparked this question were some truly optional fields that would naturally map to Nullable. I ran across your answer [here](http://stackoverflow.com/questions/4763875/does-protobuf-net-support-nullable-types). Customizing the xslt strikes me as not simple. I would probably be more tempted to use a default or a flag to indicate a null value. Do you intend to support Nullable in .GetProto ? – Watsontap Jul 18 '12 at 08:17
  • @Kenn I will *try* to support whatever I can ;p That will map to "optional" in .proto, which should be fine. – Marc Gravell Jul 18 '12 at 08:19
  • That would make .GetProto asymmetric with the code generator, if I'm not mistaken, considering the generator does not map optional to Nullable. – Watsontap Jul 18 '12 at 08:33
  • @Kenn c# has more features than .proto; it is always going to be asymmetric in some way. Equally, .proto has no concept of "arrays" vs "lists" vs "ilists" - it just has "repeated". And IIRC (although possibly only with `detectMissing` enabled), protogen *does* use `Nullable`, along with conditional serialization specifies. Pretty sure `Nullable` is part of the the xslt. – Marc Gravell Jul 18 '12 at 08:42
  • Point taken, Marc. Thanks for the tip on detectMissing. It's a shame I didn't make a new stackoverflow question. – Watsontap Jul 18 '12 at 09:24