Cómo elegir entre protobuf-csharp-port y protobuf-net

Question

Recientemente tuve que buscar una conexión C# de la biblioteca Protocol Buffers desarrollada originalmente por Google. Y adivinen qué, encontré dos proyectos propiedad de dos personas muy conocidas aquí: protobuf-csharp-port, escrito por Jon Skeet y protobuf-net, escrito por Marc Gravell. Mi pregunta es simple: ¿cuál tengo que elegir?

Me gusta bastante la solución de Marc, ya que me parece más cercana a C# philisophy (por ejemplo, puede agregar atributos a las propiedades de la clase existente) y parece que admite tipos incorporados de .NET como System .Guardia.

Estoy seguro de que ambos son realmente grandes proyectos, pero ¿cuál es su opinión?

Answer 1

Estoy de acuerdo con los puntos de Jon; si está codificando en múltiples entornos, entonces su versión le proporciona una API similar a las otras implementaciones "centrales". protobuf-net es mucho más similar a cómo se implementan la mayoría de los serializadores .NET, por lo que es más familiar (IMO) para los desarrolladores de .NET. Y como señala Jon, la salida binaria en bruto debe ser idéntica para que pueda volver a implementarla con una API diferente si lo necesita más adelante.

Algunos puntos de re-protobuf red que son específica a esta aplicación:

• obras con tipos existentes (no sólo los tipos generados a partir de .proto)
• trabaja bajo cosas como WCF y memcached
• se puede utilizar para implementar ISerializable para los tipos existentes
• admite los métodos de devolución de llamada de herencia * y serialización
• apoya patrones comunes como ShouldSerialize[name]
• trabajos con los tipos existentes decoradas (XmlType/XmlElement o DataContract/DataMember) - significado (por ejemplo) que los modelos de LINQ a SQL serializan fuera de la caja (siempre ya que la serialización está habilitada en el DBML)
• en v2, funciona para tipos POCO sin ningún atributo
• en v2, funciona en .NET 1.1 (no estoy seguro de que sea una gran característica de venta) y la mayoría de los otros marcos (incluido monotouch - ¡Hurra!)
• posiblemente (todavía no implementado) v2 podría apoyar la plena-gráfico * serialización (no sólo serialización árbol)

(* = estas características utilizan 100% válida binaria protobuf, pero que puede ser difícil de consumir de otros idiomas)

Answer 2

¿Está utilizando otros idiomas en su proyecto también? Si es así, mi puerto C# te permitirá escribir códigos similares en todas las plataformas. Si no, el puerto de Marc es probablemente más idiomático C# para empezar. (Intenté hacer que mi código se "sintiera" como C# normal, pero el diseño se basa claramente en el código de Java para empezar, deliberadamente, para que también sea familiar para quienes usan Java).

Por supuesto, uno de las maravillas de esto es que puedes cambiar de opinión más adelante y estar seguro de que todos tus datos seguirán siendo válidos a través del otro proyecto; deben ser absolutamente compatibles con los binarios (en términos de datos serializados), por lo que yo sé .

Answer 3

Acabo de cambiar de protobuf-CSharp puertos a protobuf-net porque:

• protobuf-net es más ".net como", es decir, los descriptores de serializar los miembros en lugar de la generación de código .
• Si desea compilar archivos protobuf-csharp-port .proto, debe realizar un proceso de 2 pasos, es decir, compilar con protoclo para .protobin y compilarlo con protoGen. protobuf-net hace esto en un solo paso.

Answer 4

En mi caso, quiero utilizar búferes de protocolo para reemplazar un modelo de comunicación basado en xml entre un cliente .NET y un servidor j2ee. Como ya estoy usando la generación de código, iré a la implementación de Jon.

Para proyectos que no requieren interoperabilidad de java elegiría la implementación de Marc, especialmente desde que v2 permite trabajar sin anotaciones.

Answer 5

Según es GitHub project site protobuf-CSharp puertos ahora se ha doblado en el principal proyecto de protocolo de Google tampones, por lo que será la aplicación oficial de .NET protobuf 3. protobuf-net sin embargo era last updated in 2013, aunque se han estado some commits recently in GitHub.