Using Protocol buffer as general Data object?

views:

641

answers:

+6 Q:

Using Protocol buffer as general Data object?

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.

+5 A:

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.

Jon Skeet 2009-11-25 19:55:16

I think the fact that they're immutable actually helps, not hurts, when it comes to using protocol buffers like this. They're immutable value objects just like String.

Laurence Gonsalves 2009-11-25 20:22:54

It certainly helps in some cases, when you can write code in a functional style. It partly depends on the problem and partly on the developers :)

Jon Skeet 2009-11-25 20:40:58

Immutable really helps in some cases, for unknown reasons there existing some public constructions with a dozen+ or so parameters, all assigned to final fields. A builder is great but tedious and boilerplate to write each time. It's also tricky to get the logic of required vs. optional right, such that the build() method blows up if required fields have been omitted.

Mark Renouf 2009-11-25 21:11:05

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?

hbunny 2009-11-25 20:01:09

This is actually a step towards exactly that. Right now a set of interfaces dictates our data layer, back end RPC *and* to some extend a RESTful web service layer. *PAIN*. Step #1 is to replace the back end with protocol buffers to decouple that from the rest. But that's an excellent point. If I just switch everything to protobufs, the only thing I've decoupled is the link between client and RPC services while all other layers will depend on the Message objects... BAD.

Mark Renouf 2009-11-25 21:13:59

ansaurus

tags:

views:

answers:

Using Protocol buffer as general Data object?

related questions