Quelles sont les différences entre les XmlSerializer et BinaryFormatter

Question

J'ai passé une bonne partie de temps la semaine dernière à travailler sur la sérialisation. Pendant ce temps, j'ai trouvé de nombreux exemples, soit par le BinaryFormatter ou XmlSerializer. Malheureusement, ce que je ne trouve pas des exemples ont été globalement les détails des différences entre les deux.

La genèse de ma curiosité réside dans le pourquoi BinaryFormatter peut désérialiser directement à une interface tandis que le XmlSerializer n'est pas. Jon Skeet dans une réponse à " Castings à plusieurs (types inconnus) lors de l'exécution " fournit un exemple de sérialisation binaire direct à une interface. Stan R. m'a donné les moyens d'atteindre mon objectif en utilisant le XmlSerializer dans sa réponse à « XML objet désérialisation à l'interface ."

Au-delà de l'évidence de l'BinaryFormatter utilise sérialisation binaire tandis que le XmlSerializer utilise XML je voudrais mieux comprendre les différences fondamentales. Quand utiliser l'un ou l'autre ainsi que les avantages et les inconvénients de chacune d'elles.

Answer 1

La raison pour laquelle un formateur binaire est capable de désérialiser directement à un type d'interface est parce que quand un objet est à l'origine sérialisé à un méta-données du flux binaire contenant des informations de type et de l'assemblage est collé avec les données d'objet. Cela signifie que lorsque le binaire formatter désérialise l'objet qu'il connaît son type, construit l'objet correct et vous pouvez alors lancer ce à un type d'interface objet implémente.

Le sérialiseur XML sur le otherhand sérialise juste un schéma et sérialise uniquement les champs publics et les valeurs de l'objet et aucune information de type alors que d'autres (par exemple interface les outils de type).

Voici un bon poste, .NET sérialisation, en comparant la BinaryFormatter , SoapFormatter et XmlSerializer . Je vous recommande de regarder le tableau suivant qui, en plus du mentionné précédemment serializers inclut le DataContractSerializer , NetDataContractSerializer et protobuf-net.

Answer 2

Juste pour peser ...

La différence évidente entre les deux est « binaire vs xml », mais il ne va beaucoup plus loin que cela:

• champs (BinaryFormatter = bf) vs membres publics (typiquement propriétés) (XmlSerializer = xs)
• type de métadonnées sur la base (bf) vs (xs) sur la base de contrats-
• Version fragile (bf) vs la version à tolérance (xs)
• "graphe" (bf) vs "arbre" (xs)
• .NET spécifique (bf) vs portables (xs)
• opaque (bf) vs lisible par l'homme (xs)

En discussion des raisons pour lesquelles BinaryFormatter peut être fragile, voir ici .

Il est impossible de discuter de ce qui est plus grand; toutes les métadonnées de type dans BinaryFormatter peut le rendre plus grand. Et XmlSerializer peut travailler avec une compression très comme gzip.

Cependant, il est possible de prendre les points forts de chacun; par exemple Google ont ouvert leur propre sourced format de sérialisation de données, « tampons de protocole ». Ceci est:

• contractualisation
• portable (voir liste des implémentations )
• version tolérante
• arborescente
• opaque (bien qu'il existe des outils pour afficher les données lorsqu'il est combiné avec un .proto)
• généralement « contrat premier », mais certaines implémentations permettent contrats implicites basé sur la réflexion

Mais surtout, ce sont des données très denses (pas de métadonnées de type, représentation binaire pur, des balises courtes, des trucs comme base 7 longueur variant de codage), et très efficace pour traiter (pas de structure xml complexe, pas de chaînes de caractères pour correspondre à membres, etc).

Je pourrais être un peu biaisé; Je maintiens l'une des mises en œuvre (y compris plusieurs appropriés pour C # /. NET), mais vous remarquerez que j'ai pas  lié à une mise en œuvre spécifique ; le format est soumis à ses propres mérites ;-P

Answer 3

Le sérialiseur XML produit XML et aussi un schéma XML (implicitement). Il produira XML conforme à ce schéma.

L'une des conséquences est qu'il ne sérialisation rien qui ne peut être décrit dans le schéma XML. Par exemple, il n'y a pas moyen de distinguer entre une liste et un tableau en XML Schema, de sorte que le schéma XML produit par le sérialiseur peut être interprétée de toute façon.

sérialisation d'exécution (dont le BinaryFormatter fait partie) sérialise les types .NET réels de l'autre côté, donc si vous envoyez un List<int>, l'autre côté obtiendra un List<int>.

Cela fonctionne évidemment mieux si l'autre côté est en cours d'exécution .NET.

Answer 4

Le XmlSerializer sérialise le type en lisant toutes les propriétés de type qui ont à la fois un getter public et un setter public (et aussi les champs publics). En ce sens, le XmlSerializer sérialise / désérialise la « vue du public » de l'instance.

Le binaire formatter, en revanche, sérialise un type par sérialisation « internals », à savoir ses champs de l'instance. Tous les champs qui ne sont pas marqués comme [NonSerialized] seront sérialisés au flux binaire. Le type lui-même doit être marqué comme [Serializable] que doivent tous les champs internes qui sont également à sérialisés.

Answer 5

Je suppose que l'un des plus importants est que les sérialisation binaire peut sérialiser les deux membres publics et privés, tandis que l'autre ne fonctionne qu'avec les établissements publics.

Ici, il fournit une comparaison très utile entre ces deux en termes de taille. Il est une question très importante, parce que vous pouvez envoyer votre objet sérialisé à une machine distante.

http: //www.nablasoft.com/alkampfer/index.php/2008/10/31/binary-versus-xml-serialization-size/