So wählen Sie zwischen protobuf-csharp-port und protobuf-net

Ich musste kürzlich nach einer C # -Portierung der Protokollpuffer-Bibliothek suchen, die ursprünglich von Google entwickelt wurde. Und raten Sie mal, ich habe hier zwei Projekte gefunden, die beiden sehr bekannten Personen gehören: protobuf-csharp-port , geschrieben von Jon Skeet und protobuf-net , geschrieben von Marc Gravell . Meine Frage ist einfach: Welches muss ich wählen?

Marcs Lösung gefällt mir sehr gut, da sie mir näher an der C # -Philosophie liegt (Sie können beispielsweise nur Eigenschaften zu den Eigenschaften der vorhandenen Klasse hinzufügen) und anscheinend integrierte .NET-Typen wie System.Guid unterstützt.

Ich bin mir sicher, dass beide wirklich großartige Projekte sind, aber was ist Ihre Meinung?

Ich stimme Jons Punkten zu; Wenn Sie über mehrere Umgebungen codieren, bietet Ihnen seine Version eine ähnliche API wie die anderen "Kern" -Implementierungen. protobuf-net ähnelt viel mehr der Implementierung der meisten .NET-Serialisierer und ist daher für .NET-Entwickler vertrauter (IMO). Und wie Jon Noten - der rohe Binärausgang sollte identisch sein , so dass Sie mit einer anderen API neu implementieren können , wenn Sie später benötigen.

Einige Punkte bezüglich Protobuf-Net, die für diese Implementierung spezifisch sind :

• funktioniert mit vorhandenen Typen (nicht nur generierte Typen aus .proto)
• funktioniert unter Dingen wie WCF und memcached
• kann verwendet werden, um ISerializablefür vorhandene Typen zu implementieren
• unterstützt Vererbungs- * und Serialisierungs-Rückrufmethoden
• unterstützt gängige Muster wie ShouldSerialize[name]
• funktioniert mit vorhandenen dekorierten Typen ( XmlType/ XmlElementoder DataContract/ DataMember) - was (zum Beispiel) bedeutet, dass LINQ-zu-SQL-Modelle sofort serialisiert werden (solange die Serialisierung in der DBML aktiviert ist)
• Funktioniert in Version 2 für POCO-Typen ohne Attribute
• funktioniert in v2 in .NET 1.1 (nicht sicher, ob dies eine große Verkaufsfunktion ist) und den meisten anderen Frameworks (einschließlich Monotouch - yay!)
• möglicherweise (noch nicht implementiert) v2 die Vollgraph * -Serialisierung (nicht nur die Baumserialisierung).

(* = Diese Funktionen verwenden 100% gültige Protobuf-Binärdateien, die jedoch möglicherweise nur schwer in anderen Sprachen verwendet werden können.)

Verwenden Sie in Ihrem Projekt auch andere Sprachen? In diesem Fall können Sie über meinen C # -Port auf allen Plattformen ähnlichen Code schreiben. Wenn nicht, ist Marc's Port wahrscheinlich zunächst idiomatischer C #. (Ich habe versucht, meinen Code wie normales C # "fühlen" zu lassen, aber das Design basiert eindeutig auf dem Java-Code, damit er auch denjenigen vertraut ist, die Java verwenden.)

Eine der Schönheiten dabei ist natürlich, dass Sie Ihre Meinung später ändern können und sicher sein können, dass alle Ihre Daten über das andere Projekt weiterhin gültig sind - sie sollten für mich absolut binär kompatibel sein (in Bezug auf serialisierte Daten) bin mir bewusst.

Laut der GitHub-Projektseite wurde protobuf-csharp-port jetzt in das Hauptprojekt von Google Protocol Buffers integriert. Es handelt sich also um die offizielle .NET-Implementierung von protobuf 3. protobuf-net wurde jedoch zuletzt 2013 aktualisiert , obwohl dies bereits geschehen ist Einige Commits wurden kürzlich in GitHub ausgeführt .

Ich habe gerade von protobuf-csharp-port zu protobuf-net gewechselt, weil:

• protobuf-net ist eher ".net like", dh Deskriptoren zum Serialisieren von Mitgliedern anstelle der Codegenerierung.
• Wenn Sie protobuf-csharp-port .proto-Dateien kompilieren möchten, müssen Sie einen zweistufigen Prozess ausführen, dh mit protoc zu .protobin kompilieren und diesen dann mit protoGen kompilieren. protobuf-net erledigt dies in einem schritt.

In meinem Fall möchte ich Protokollpuffer verwenden, um ein XML-basiertes Kommunikationsmodell zwischen einem .net-Client und einem j2ee-Backend zu ersetzen. Da ich bereits die Codegenerierung verwende, werde ich mich für Jons Implementierung entscheiden.

Für Projekte, die kein Java Interop erfordern, würde ich die Implementierung von Marc wählen, zumal v2 das Arbeiten ohne Anmerkungen ermöglicht.