BinaryFormatter "verliert" Daten?

Question

Hallo!

Ich habe ein Problem, und zwar kommt es sporadisch vor, dass bei meiner deserialisierte Klasse einige Werte Fehlen.

Das komische ist, die Fehlenden Objekte sind mehrfach referenziert, also einmal in einer List, ein weiteres mal in einem Dictionary.

Kann es also sein, dass die (de)serialisierung Daten mit null wiederherstellt?

Es kann auch am Programm liegen, dass es vielleicht die Daten löscht, aber wie gesagt, es ist nicht leicht, die Referenzen aus BEIDEN Listen zu finden und zu löschen,
geschweige denn habe ich eine solche Routine geschrieben.

mfg BlackLine

Answer 1

Hallo,

ohne konkretere Angaben (z. B. hilfreiche Codeschnippsel) ist das schwer zu beantworten.

Grundsätzlich solltest Du dir vor Augen halten, dass der BinaryFormatter Kopien der Objekte erstellt.
Wenn die von Dir angebenen Liste und Dictionary nicht in einem Rutsch serialisiert werden,
so hast Du nach dem Deserialisieren unterschiedliche Instanzen.
Implementieren Deine Objekte nicht Equals, so wird ein Vergleich sie als unterschiedlich auffassen.

Gruß Elmar

Answer 2

Hallo,

Dane für die Antwort.

Das mit dem Equals kommt mir sehr passend vor, habe sowas nämlich nicht implementiert und mich immer gefragt, wie der serialisierer das macht (toString?!??)
Ich habe bei meinem Programm zB. Zwei Spieler, Spieler A und Spieler B. Deren Vornamen und Nachname sind gleich, wie unterscheide ich sie dann? Pointer oder sowas gibts ja nicht, oder kann aus einem Object ein einzigartiger Wert ausgelesen werden?

Ich sollte also versuchen, während des Serialisierens möglichst keine Änderungen an den Daten mehr zuzulassen?

Ich hoffe, ich bekomme es so hin.

mfg

Answer 3

Hallo,

für eine vollständige Unterstützung inkl. Generika solltest Du IEquatable<T> implementieren,
was auch Equals und GetHashCode (für Dictionary) beinhaltet.

Bei Klassen mit Personendaten (Spieler) kommt man nicht um einen eindeutigen Schlüssel herum,
denn es laufen einfach zu viele Meiers und Müllers rum ;-)
Am einfachsten baust Du eine Guid ein, die Du für die Prüfung auf Gleichheit verwendest.
Ein Integer tuts zwar auch; dann brauchst Du aber wieder eine Stelle,
wo Du die letzte vergebene Nummer verwaltest.

Gruß Elmar

Answer 4

Hallo,

was ich aus Guid rauslesen konnte, ist das ein KlassenAttribut.
Wie kann ich dann 2 unterschiedlich Personen der selben Klasse mit diesem Mechanismus unterscheiden?
Da ich irgendwann mit diesen Spielerdaten in eine weltweite Datenbank rein muss,
komme ich wahrscheinlich nicht um UID's rum. Diese werde ich dann auch für die serialisierung verwenden.

Dann macht auch eine IEquatable implementation Sinn.

Wenn ich dann aber zur laufzeit die selbe binary 2 mal deserialisiere, sind dann die selben Spieler auch wieder
gleich referenziert? Also verweisen bei Herr Müller aus der ersten serialisierung und Herr Müller aus der zweiten (gleiche source.ser)
beide referenzen auf das selbe Objekt im Speicher?

mfg

Answer 5

Hallo,

Guids (Global Unique Identifier) sind mehr als nur ein Attribut.
Sie eignen sich überall dort, wo man eine eindeutige Identifikation benötigt,
die man anderweitig nicht ableiten kann.

Bei Serialisieren solltest Du eine Person nicht mehrmalig serialisieren,
sondern nur die Guid in den verwendenden Klassen. Und den Zugriff
der weiteren Daten über eine (nicht serialisierte) Eigenschaft.
So vermeidest Du potentielle Dopplungen - sonst wird aus einem
Heinz Müller doch mal ein Karl Schröder ;-)
und minimierst die zu serialisierenden Datenmenge.

So würde man es bei einer relationalen Datenmodell implementieren.
Anstatt der Serialisierung kannst  Du überlegen, ob nicht eine kleine
Datenbank sinnvoll ist (z. B. SQL Server Compact oder SQLite) -
und dann in Verbindung mit dem ADO.NET Entity Framework

Gruß Elmar