La versión de Jon es en gran parte un puerto de la versión de Java, por lo que tiene un enfoque API y de diseño muy similar. También es AFAIK completamente por contrato primero, es decir, desde .proto.
Mi versión se produce en más de una perspectiva .NET, mirando a lo que es común en serializadores .NET - objetos tan mutables, equipar a los tipos existentes, código primero (aunque puede todavía lo hacen código de generación de un .proto si lo desea), etc. Incluso puede inferir datos de los atributos utilizados por XmlSerializer y DataContractSerializer para trabajar lado a lado con el código existente, y puede conectarse tanto a la comunicación remota (a través de ISerializable) como a WCF (a través de atributos o configuración). Por lo tanto, está profundamente arraigado en el ecosistema .NET. También incluyo el soporte herencia (ya que es tan común en los otros serializadores .NET), pero esto es un poco complicado de mapear a otras plataformas ya que no tiene representación directa en .proto.
Los datos binarios deben ser idénticos; ese es en gran medida el punto del formato; p Es principalmente una elección de qué API podría ser más apropiada para usted.
Para sus necesidades, trabajando lado a lado con código C++ y Java en el mismo sistema, y con las definiciones .proto existentes, sugiero que la versión de Jon puede ser la opción más adecuada para usted.
Sin embargo, si usted está haciendo .NET única, o está haciendo con .NET de interoperabilidad con el código externo (es decir, no le importa lo que la lengua del "otro lado" usos, ya que es suficiente con preocuparse por su propio código), entonces IMO protobuf-net puede ser una manera bastante fácil de consumir los datos; especialmente si tiene un sistema existente que ahora desea serializar (o: serialice más rápido/más pequeño).
Gracias Marc. Hemos utilizado su versión desde el primer día, pero estábamos buscando aclaraciones, especialmente a medida que más equipos comienzan a usar las bibliotecas. –
@Ray, sigue usándolo y disfruta; p –