Come scegliere tra protobuf-csharp-port e protobuf-net

Question

Recentemente ho dovuto cercare un porting C# della libreria Protocol Buffers originariamente sviluppata da Google. E indovina un po ', ho trovato due progetti di proprietà di due persone molto conosciute qui: protobuf-csharp-port, scritto da Jon Skeet e protobuf-net, scritto da Marc Gravell. La mia domanda è semplice: quale devo scegliere?

Mi piace molto la soluzione di Marc in quanto mi sembra più vicina alla filosofia C# (ad esempio, è possibile solo aggiungere attributi alle proprietà della classe esistente) e sembra che possa supportare i tipi integrati di .NET come System .Guid.

Sono sicuro che entrambi sono davvero grandi progetti, ma qual è il tuo parere?

Answer 1

Sono d'accordo con i punti di Jon; se si sta codificando su più ambienti, la sua versione fornisce un'API simile alle altre implementazioni "core". protobuf-net è molto più simile alla maggior parte dei serializzatori .NET implementati, quindi è più familiare (IMO) agli sviluppatori .NET. E come nota Jon - l'output binario grezzo dovrebbe essere identico allo in modo da poterlo ri-implementare con un'API diversa se è necessario in seguito.

Alcuni punti ri protobuf-net che sono specifica a questa implementazione:

• opere con tipi esistenti (non solo i tipi generati da Proto)
• opere sotto le cose come WCF e memcached
• può essere utilizzato per implementare ISerializable per i tipi esistenti
• supporta metodi di callback di ereditarietà * e serializzazione
• supporta modelli comuni come ShouldSerialize[name]
• opere con i tipi esistenti decorate (XmlType/XmlElement o DataContract/DataMember) - senso (per esempio) che i modelli LINQ to SQL serializzare gli out-of-the-box (a condizione come la serializzazione è abilitato nel DBML)
• in v2, funziona per i tipi POCO senza attributi
• in v2, lavora a .NET 1.1 (non sono sicuro questa è una caratteristica di vendita enorme) e la maggior parte degli altri framework (compresi MonoTouch - Sìì!)
• eventualmente (non ancora implementata) v2 potrebbe supportare intero grafico * serializzazione (non solo albero serializzazione)

(* = queste funzionalità utilizzano 100% valido protobuf binario, ma che potrebbe essere difficile consumare da altre lingue)

Answer 2

Stai anche utilizzando altre lingue nel tuo progetto? Se è così, la mia porta C# ti permetterà di scrivere codice simile su tutte le piattaforme. Altrimenti, la porta di Marc è probabilmente più C idiatica con cui iniziare. (Ho cercato di far "sentire" il mio codice come normale C#, ma il design è chiaramente basato sul codice Java per iniziare, deliberatamente in modo che sia familiare anche a coloro che usano Java.)

Naturalmente uno delle bellezze di questo è che puoi cambiare idea in seguito e essere sicuro che tutti i tuoi dati saranno ancora validi attraverso l'altro progetto - dovrebbero essere assolutamente compatibili con i binari (in termini di dati serializzati), per quanto ne so .

Answer 3

ho appena passato da protobuf-csharp-porta protobuf-rete perché:

• protobuf-net è più "net come", cioè descrittori serializzare membri invece di generazione di codice .
• Se si desidera compilare i file protobuf-csharp-port .proto, è necessario eseguire un processo in 2 fasi, ad esempio compilare con protoc in .protobin e quindi compilarlo con protoGen. protobuf-net fa questo in un unico passaggio.

Answer 4

Nel mio caso, desidero utilizzare i buffer di protocollo per sostituire un modello di comunicazione basato su xml tra un client .net e un backend j2ee. Dato che sto già usando la generazione di codice, andrò per l'implementazione di Jon.

Per i progetti che non richiedono l'interoperabilità java, sceglierei l'implementazione di Marc, soprattutto perché la v2 consente di lavorare senza annotazioni.

Answer 5

In base ad esso è GitHub project site protobuf-csharp porte ora è stato piegato nel progetto principale di Google buffer protocollo, in modo che sarà l'applicazione ufficiale di .NET protobuf 3. protobuf-net tuttavia era last updated in 2013, anche se ci sono stato some commits recently in GitHub.