BinaryFormatter ou Serialisation "manuelle"

Bonjour à tous,

Je me pose quelques questions concernant la sérialisation par rapport a mes projets en cours, pour pouvoir notamment enregistrer divers paramètres dans un fichier binaire.

Prenons un exemple :aie:

Partons du principe qu'on utilise une classe nommée MaConfiguration (quelle originalité :D), contenant uniquement des string et des int (pour simplifier la chose), représentants les parametres de configuration de l'application.

Une fois un objet de type MaConfiguration instancié, pour en sauver le contenu au format binaire, il y a 2 choix (arrêtez moi si je me trompe):

A. Utiliser l'objet BinaryFormater du Framework .NET : De ce que j'ai compris, ça permet de stocker un objet complet en format binaire.

B. Enregistrer le contenu a la main (a coup de BitConverter.GetBytes).


Avantage du BinaryFormater :
- La classe MaConfiguration peut changer, le code pour la sérialization ne changera pas

Inconvénients :
- L'objet complet est sérialisé


Avantage de la serialisation "a la main" :
- On peut stocker uniquement les valeurs des champs, ce qui permet d'économiser quelques ko sur le fichier généré.

Inconvénients :
- Dès qu'on change un bout de la classe MaConfiguration, il faut revoir le code d'enregistrement


Si je fait appel à vous, c'est pour savoir si déjà, si j'ai bien compris le principe de fonctionnement du BinaryFormater :o.

Ensuite, pour savoir si vous voyez d'autres avantages / inconvénients à ces deux solutions (histoire que je puisse mieux m'orienter vers l'une ou l'autre) :D

A vos claviers, et merci d'avance :o

Citation:

---

Envoyé par LudVichzme

Inconvénients :
- L'objet complet est sérialisé

---

Avec BinaryFormatter tu ne sérialises pas nécessairement tout l'objet. Tu peux spécifier que certains champs ne sont pas sérialisés, avec l'attribut NonSerialized.

Citation:

---

Envoyé par tomlev

Avec BinaryFormatter tu ne sérialises pas nécessairement tout l'objet. Tu peux spécifier que certains champs ne sont pas sérialisés, avec l'attribut NonSerialized.

---

C'est exact, mais faire attention, cependant :

sauf erreur de ma part, c'est en fait tout le graphe d'objets accessibles (par références non nulles bien sûr) depuis l'instance "principale" passée à ce moment là au serializer que .NET va considérer (pas seulement les champs de "types valeurs" ou "assimilés" de cette instance) ; il faudra donc considérer l'usage de cet attribut, donné par tomlev ci dessus, y compris pour vos associations (inter-objets) qui parte de la classe effective de cette instance (i.e, son type à l'exécution vs. son type statique déclaré), si vous voulez exclure une partie de ce graphe pour votre besoin.

Sans cela, vous pourriez serialiser "trop". Peut être pas gênant, mais il faut en être conscient.

Bon, juste un rappel, si vous saviez déjà.

'HTH

Justement pour éviter tout ces désagréments je préfère créer une classe spécialement dédicacée à contenir les données. Même si c'est une charge de travail supplémentaire, on moins on es sur d'éliminer une possibilité de bug latent parce que autant avec la serialisation xml on voit exactement ce qui est séralisé ou pas, avec la serialisation binaire le problème prends une autre mesure ...