I can certainly second Ted's comment. I would go so far as to say that Jackson's multi-encoding/protocol support is intended for exposing the same POJOs multiple ways but should not be regarded as an endorsement of coupling tiers of your application (internal serialization versus API/wire serialization) together by reusing the same objects.
— [email protected] | Multifarious, Inc. | http://mult.ifario.us/ On Tue, Aug 11, 2015 at 2:44 PM, Josh Elser <[email protected]> wrote: > Ted Dunning wrote: > >> On Tue, Aug 11, 2015 at 1:14 PM, Josh Elser<[email protected]> wrote: >> >> Andrew Purtell wrote: >>> >>> That might be because protobuf documentation, and I'd assume accumulated >>>> practice based upon it, warns against using generated pbuf objects >>>> directly >>>> as model classes. (See the "Protocol Buffers and O-O Design" callout on >>>> https://developers.google.com/protocol-buffers/docs/javatutorial.) >>>> >>>> Assuming that's the case, that makes sense. It was just not clear to me >>> if >>> Julian and I were just talking past each other or if there was some >>> fallacy >>> I was suggesting. >>> >> >> >> This differentiation between wire protocol and API is something that I >> have >> seen repeatedly in ex-Googlers. I was a bit curious since it seemed nice >> to >> have one definition for both levels. >> >> My opinion has verged to be 100% with the Google philosophy of separation >> after watching how the MapR internals work. This kind of separation has >> really paid off in many instances. Having too tight a lock between wire >> and >> API would have been nearly disastrous for either comprehensibility of the >> API or efficiency of the wire. I can't share specifics, but if second-hand >> opinions are useful, you now have mine. >> >> > Absolutely, opinions are very useful here, Ted. Much appreciated. I'm > trying to feel my way through the cleanest approach without stepping on > architected toes. >
