Protocol Buffer pour .NET va-t-il être plus léger/rapide que Remoting (SerializationFormat.Binary) ? Y aura-t-il un support de première classe pour lui en termes de langage/de cadre ? c.-à-d. sera-t-il géré de manière transparente comme avec Remoting/WebServices ?
Réponses
Trop de publicités?
Je doute fort qu'il ait un jour un support direct du langage ou même du framework - c'est le genre de choses qui sont parfaitement gérées par des bibliothèques tierces.
Mon propre portage du code Java est explicite - vous devez appeler des méthodes pour sérialiser/désérialiser. (Il existe des stubs RPC qui vont automatiquement sérialiser/désérialiser, mais pas encore d'implémentation RPC).
Le projet de Marc Gravell s'intègre très bien à WCF - pour autant que je sache, il suffit de lui dire (une fois) d'utiliser les tampons de protocole pour la sérialisation, et le reste est transparent.
En termes de vitesse, vous devez tenir compte des éléments suivants La page de référence de Marc Gravell . Mon code a tendance à être légèrement plus rapide que le sien, mais les deux sont beaucoup, beaucoup plus rapides que les autres options de sérialisation/désérialisation du framework. Il faut souligner que les tampons de protocole sont également beaucoup plus limités - ils n'essaient pas de sérialiser des types arbitraires, seulement ceux qui sont supportés. Nous allons essayer de prendre en charge un plus grand nombre de types de données courants (décimal, DateTime, etc.) d'une manière portable (en tant que leurs propres messages de tampon de protocole) à l'avenir.
Marc Gravell
Points
482669
Certaines mesures de performance et de taille sont sur cette page . Je n'ai pas encore mis les statistiques de Jon sur cette page, parce qu'elle est un peu ancienne (Jon : nous devons corriger cela !).
Re être transparent ; protobuf-net peut s'accrocher à WCF via le contrat ; notez que cela fonctionne bien avec MTOM sur basic-http aussi. Cela ne fonctionne pas avec Silverlight, cependant, puisque Silverlight n'a pas de point d'injection. Si vous utilisez svcutil, vous devez également ajouter un attribut à la classe (via une classe partielle).
Re BinaryFormatter (remoting) ; oui, cela a un soutien total ; vous pouvez faire cela simplement par un trivial ISerializable (c'est-à-dire qu'il suffit d'appeler le Serializer avec les mêmes arguments). Si vous utilisez protogen pour créer vos classes, alors il peut le faire pour vous : vous pouvez activer cela à la ligne de commande via les arguments (ce n'est pas activé par défaut car BinaryFormatter ne fonctionne pas sur tous les frameworks [CF, etc]).
Il est à noter que pour les très petits objets (instances uniques, etc.) dans le cadre d'un remoting local (IPC), les valeurs brutes de l'indicateur BinaryFormatter Les performances sont en fait meilleures - mais pour les graphes non triviaux ou les liens distants (remoting réseau) protobuf-net peut le surpasser assez bien.
Je dois également noter que le format filaire des tampons de protocole ne supporte pas directement l'héritage ; protobuf-net peut le simuler (tout en conservant la compatibilité filaire), mais comme avec XmlSerializer, vous devez déclarer les sous-classes à l'avance.
Pourquoi y a-t-il deux versions ?
Les joies de l'open source, je suppose ;-p Jon et moi avons déjà travaillé sur des projets communs, et avons discuté de la fusion de ces deux-là, mais le fait est qu'ils visent deux scénarios différents :
- dotnet-protobufs (celui de Jon) est un portage de la version java existante. Cela signifie qu'il a une API très familière pour quiconque utilise déjà la version java, et qu'il est construit sur des constructions java typiques (classes de constructeurs, classes de données immuables, etc) - avec quelques modifications en C#.
-
protobuf-net (celui de Marc) est une réimplémentation de base qui suit le même format binaire (en effet, une exigence critique est que vous puissiez échanger des données entre différents formats), mais en utilisant les idiomes typiques de .NET :
- classes de données mutables (pas de builders)
- les spécificités des membres de la sérialisation sont exprimées dans des attributs (comparable à
XmlSerializer,DataContractSerializeretc)
Si vous travaillez sur des clients Java et .NET, celui de Jon est probablement un bon choix pour l'API familière des deux côtés. Si vous êtes purement .NET, protobuf-net a des avantages - l'API familière de style .NET, mais aussi :
- vous n'êtes pas forcé pour être contractuel d'abord (bien que vous le puissiez, et un générateur de code est fourni)
- vous pouvez réutiliser vos objets existants (en fait,
[DataContract]y[XmlType]peuvent souvent être utilisées sans aucune modification). - elle supporte entièrement l'héritage (qu'elle réalise sur le fil en usurpant l'encapsulation) (peut-être unique pour une implémentation de tampons de protocole ? notez que les sous-classes doivent être déclarées à l'avance)
- il fait tout son possible pour se brancher sur les principaux outils .NET et les exploiter (
BinaryFormatter,XmlSerializer, WCF,DataContractSerializer) - ce qui lui permet de fonctionner directement comme un moteur de remoting. Ce serait vraisemblablement une séparation assez importante du tronc java principal pour le portage de Jon.
En ce qui concerne leur fusion, je pense que nous serions tous deux ouverts à cette idée, mais il semble peu probable que vous souhaitiez disposer des deux ensembles de fonctionnalités, puisqu'ils visent des exigences tellement différentes.
