Question

We re introducing protocol buffers as the new transport for some back end RPC services. Because there s resistance to manually shuttling data between different forms of similar objects, I can forsee the Protocol Buffer instances being passed up the stack a bit higher than just to the RPC server interface.

Is this something that I should try to avoid? Is it safe to treat a protocol buffer object like a plain data holder, with the nice convenience that it can quickly and efficiently be transformed into and out of binary?

The other reason I see it as being a nice way to generate data objects is that the notion of required/optional fields and the automatically generated builder interface.

Answer 1

Well, they re not terribly convenient to use that way as they re immutable - you could pass the builders around, but that makes for rather long type names. It also means you re limited to the data types supported by protocol buffers (and your own messages).

It s safe to do this, but it doesn t always create the nicest of designs. On the other hand, sometimes it s just what the doctor ordered :)

I suggest you experiment - there s no "one size fits all" here.

Answer 2

In general, I design the layers of my systems so that implementation details from one layer don t leak into one another. I don t have direct experience of Google s Protocol Buffers, but it sounds like you want to use the same representation for the transport and at higher layers of your system.

If you decided you wanted to stop using Protocol Buffers as the transport representation, how easy would it be to use something else?

友情链接