You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
51 lines
3.6 KiB
51 lines
3.6 KiB
Chapitre 38 : Sérialisation
|
|
|
|
La sérialisation consiste à transformer un objet ou un ensemble d'objets qui se réfèrent les uns aux autres en un flux de bytes ou XML.
|
|
L'objectif est de pouvoir conserver ces données ou de les transmettre.
|
|
La désérialisation fonctionne dans le sens inverse : elle permet de transformer un flux de bytes ou des données XML en un objet ou graphe d'objets en mémoire.
|
|
|
|
La sérialisation et la désérialisation sont utilisées pour :
|
|
- transmettre des objets sur le réseau ou en dehors des limites de l'application,
|
|
- stocker et persister des objets dans des fichies ou des bases de données.
|
|
(plus rarement) - cloner des objets.
|
|
|
|
Dans le framework .NET, il y a 4 mécanismes de sérialisation/désérialisation :
|
|
-1- le Data Contract Serializer,
|
|
-2- le sérialiseur binaire (uniquement pour les applications bureau),
|
|
-3- le sérialiseur XML
|
|
-4- l'interface IXmlSerializable.
|
|
|
|
Les 3 premiers permettent de sérialiser/désérialiser. Le dernier vous guide à travers l'écriture de votre propre sérialiseur/désérialiseur.
|
|
Microsoft a d'abord créé les 2 et 3 pour respectivement permettre (2) la sérialisation de graphes d'objets tout en préservant les références et (3) permettre l'interopérabilité
|
|
avec XML et SOAP dans l'envoi de messages standards.
|
|
Puis la création de WCF (Windows Communication Foundation) dans la version 3.0 du Framework .NET a conduit Microsoft à unifier ces deux sérialiseurs, d'où la naissance du (1) data contract
|
|
serializer. Ce dernier est plus simple d'utilisation et couvre les mêmes besoins que les deux autres, même s'il est un peu moins performant que le (2) pour la sérialisation binaire,
|
|
et un peu moins flexible que le (3) pour la sérialisation XML. Néanmoins, il devrait être le choix par défaut pour la majorité des besoins de sérialisation/désérialisation.
|
|
|
|
1) Data Contract Serializer
|
|
C'est la solution la plus récente et celle utilisée par WCF. Il est particulièrement efficace pour :
|
|
- l'échange d'informations dans le respect des protocoles standards,
|
|
- lorsqu'on a besoin d'une bonne tolérance aux changements de versions (des types),
|
|
- la conservation des références d'objets.
|
|
Il utilise un niveau d'abstraction à travers l'utilisation d'attributs qui rend son utilisation très simplifiée et très adaptable.
|
|
Tant que vous n'avez aucune contrainte sur la forme des données XML en sortie (pas d'attributs par exemple), il est suffisant, sinon, il faudra utiliser un XmlSerializer.
|
|
|
|
2) Binary Serializer
|
|
Il est facile à utiliser et très automatisé (encore plus que le DataContract Serializer). Il est utilisé dans des connections réseau ou lors de la communication entre applications.
|
|
Il est également plus rapide que le DataContract Serializer.
|
|
Les inconvénients sont : une très faible tolérance aux changements de versions des types, un mauvais formatage XML malgré l'utilisation possible de formateur (SOAP par exemple).
|
|
|
|
3) XmlSerializer
|
|
Il ne peut que produire de l'XML et est moins performant dans la sauvegarde des graphes d'objets (en particulier dans la conservation des références d'objets).
|
|
En revanche, il est beaucoup plus flexible dans la structure XML (éléments ou attributs...).
|
|
Il est aussi utilisé par les web services ASMX.
|
|
|
|
4) IXmlSerializable
|
|
Utiliser IXmlSerializable vous permet de créer votre propre sérialiseur/désérialiseur en utilisant XmlReader/XmlWriter. L'interface est ensuite reconnue par XmlSerializer et
|
|
DataContractSerializer et peut donc être utilisée conjointement avec eux.
|
|
|
|
Enfin, on peut ajouter aux deux premières solutions des formateurs pour formater les sorties en XML ou binaire pour correspondre à certains protocoles (SOAP par exemple).
|
|
|
|
LINQ to XML
|
|
|
|
JSON |