Comment choisir entre protobuf-csharp-port et protobuf-net
J'ai récemment dû rechercher un portage C # de la bibliothèque de tampons de protocole initialement développée par Google. Et devinez quoi, j'ai trouvé deux projets appartenant à la fois à deux personnes très connues ici: protobuf-csharp-port , écrit par Jon Skeet et protobuf-net , écrit par Marc Gravell . Ma question est simple: laquelle dois-je choisir?
J'aime bien la solution de Marc car elle me semble plus proche de la philisophie C # (par exemple, vous pouvez simplement ajouter des attributs aux propriétés de la classe existante) et il semble qu'elle puisse prendre en charge les types intégrés .NET tels que System.Guid.
Je suis sûr que les deux sont de très bons projets, mais quel est votre avis?
Je suis d'accord avec les points de Jon; si vous codez sur plusieurs environnements, sa version vous donne une API similaire aux autres implémentations "de base". protobuf-net est beaucoup plus similaire à la façon dont la plupart des sérialiseurs .NET sont implémentés, il est donc plus familier (IMO) aux développeurs .NET. Et comme le note Jon - la sortie binaire brute devrait être identique afin que vous puissiez réimplémenter avec une API différente si vous en avez besoin plus tard.
Quelques points concernant protobuf-net qui sont spécifiques à cette implémentation:
- fonctionne avec les types existants (pas seulement les types générés à partir de .proto)
- fonctionne sous des choses comme WCF et memcached
- peut être utilisé pour implémenter
ISerializablepour les types existants - prend en charge l'héritage * et les méthodes de rappel de sérialisation
- prend en charge les modèles courants tels que
ShouldSerialize[name] - fonctionne avec les types décorés existants (
XmlType/XmlElementouDataContract/DataMember) - ce qui signifie (par exemple) que les modèles LINQ-to-SQL sérialisent out- prêt à l'emploi (tant que la sérialisation est activée dans le DBML) - en v2, fonctionne pour les types POCO sans aucun attribut
- en v2, fonctionne en .NET 1.1 (pas sûr que ce soit une fonctionnalité de vente énorme) et la plupart des autres cadres (y compris monotouch - yay!)
- éventuellement (pas encore implémenté) v2 peut prendre en charge la sérialisation graphique complète * (pas seulement la sérialisation de l'arborescence)
(* = ces fonctionnalités utilisent un binaire protobuf 100% valide, mais qui peut être difficile à utiliser dans d'autres langues)
Utilisez-vous également d'autres langues dans votre projet? Si c'est le cas, mon port C # vous permettra d'écrire du code similaire sur toutes les plateformes. Sinon, le port de Marc est probablement plus idiomatique en C # pour commencer. (J'ai essayé de faire "sentir" mon code comme du C # normal, mais la conception est clairement basée sur le code Java pour commencer, délibérément afin qu'il soit familier à ceux qui utilisent Java également.)
Bien sûr, l'une des beautés de cela est que vous pouvez changer d'avis plus tard et être sûr que toutes vos données seront toujours valides via l'autre projet - elles devraient être absolument compatibles binaires (en termes de données sérialisées), pour autant que je suis au courant.
Selon c'est site du projet GitHub protobuf-csharp-port a maintenant été intégré dans le projet principal de tampons de protocole Google , donc il sera l'implémentation .NET officielle de protobuf 3. protobuf-net était cependant dernière mise à jour en 201 , bien qu'il y ait eu certains commits récemment dans GitHub .
Je viens de passer de protobuf-csharp-port à protobuf-net car:
- protobuf-net est plus ".net like", c'est-à-dire des descripteurs pour sérialiser les membres au lieu de générer du code.
- Si vous souhaitez compiler des fichiers .proto protobuf-csharp-port, vous devez effectuer un processus en 2 étapes, c'est-à-dire compiler avec Protocol en .protobin, puis compiler cela avec protoGen. protobuf-net le fait en une seule étape.
Dans mon cas, je veux utiliser des tampons de protocole pour remplacer un modèle de communication basé sur xml entre un client .net et un backend j2ee. Puisque j'utilise déjà la génération de code, je vais opter pour l'implémentation de Jon.
Pour les projets ne nécessitant pas Java interop je choisirais l'implémentation de Marc, d'autant plus que la v2 permet de travailler sans annotations.