c# protobuf-net

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



(5)

Recientemente tuve que buscar una conexión C # de la biblioteca Protocol Buffers originalmente desarrollada 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 la filosofía de C # (por ejemplo, puede agregar atributos a las propiedades de la clase existente) y parece que admite tipos incorporados .NET como System.Guid.

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

¿Estás usando otros idiomas en tu 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, una 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 totalmente compatibles con los binarios (en términos de datos serializados), en la medida en que yo Soy consciente.

Acabo de cambiar de protobuf-csharp-port a protobuf-net porque:

  • protobuf-net es más "similar a .net", es decir, descriptores para serializar miembros en lugar de 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.

En mi caso, quiero usar 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 los proyectos que no requieren interoperabilidad java elegiría la implementación de Marc, especialmente desde que v2 permite trabajar sin anotaciones.

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 observa Jon, la salida binaria en bruto debería ser idéntica para que pueda volver a implementarla con una API diferente si lo necesita más adelante.

Algunos puntos de protobuf-net que son específicos de esta implementación:

  • funciona con tipos existentes (no solo tipos generados desde .proto)
  • funciona bajo cosas como WCF y memcached
  • se puede usar para implementar ISerializable para tipos existentes
  • admite métodos de devolución de herencia y serialización
  • admite patrones comunes como ShouldSerialize[name]
  • funciona con tipos decorados existentes ( XmlType / XmlElement o DataContract / DataMember ) - lo que significa (por ejemplo) que los modelos LINQ-to-SQL se serialicen de fábrica (siempre que la serialización esté habilitada en el DBML)
  • en v2, funciona para tipos de 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 frameworks (incluido monotouch - ¡yay!)
  • posiblemente (aún no implementado) v2 podría admitir la serialización de gráficos completos * (no solo la serialización de árbol)

(* = estas funciones usan un binario de protobuf 100% válido, pero que puede ser difícil de consumir desde otros idiomas)