Deserialisieren einer Klasse, die eine ListT enthält: Warum ist die Liste anfänglich mit Nullen gefüllt?

9

Ich habe eine Klasse Bar , die ein List<Foo> enthält, wobei sowohl Foo als auch Bar ISerializable implementieren.

Beim Deserialisieren von Bar wird List<Foo> anfänglich mit (der korrekten Anzahl von) null s gefüllt; dann wird beim Verlassen des% deserialization ctor Bar jeder Deserialisierungs-ctor von Foo aufgerufen, wobei List<Foo> mit dem (richtig deserialisierten) Foo s gefüllt wird.

Warum passiert das? Ich kann es nicht in einem Testprojekt replizieren: Was immer ich versucht habe, hat dazu geführt, dass die% deserialization-Codes Foo vor Bar ctor genannt wurden. Das ist eigentlich das Verhalten, das ich möchte, da ich die Liste füllen muss, um eine Initialisierung für das deserialisierte Bar ! Zu machen!

Hat jemand eine Idee, was dazu führen könnte, dass Foo s so spät deserialisiert wird? Danke!

    
Joel in Gö 08.03.2010, 11:06
quelle

1 Antwort

5

Es ist Logik. Der Deserializer deserialisierte es Objekt für Objekt und folgte dann den Verweisen. Also richtet er zuerst die Liste mit X-Räumen ein, die eigentlich alle NULL sind.

Dann geht es hinein und deserialisiert Objekt für Objekt und setzt sie in die richtigen Referenzen.

Alle Check-Logik von Ihnen sollte NUR ausgeführt werden, nachdem die Deserialisierung abgeschlossen wurde - per Definition müssen Sie immer partielle / ungültige Zustände haben, während der Deserializer läuft.

Das Problem, warum die Dinge so spät erledigt werden, ist wahrscheinlich, dass Ihr Testszenario viel einfacher ist als die echten Daten, also macht etwas den Serializer "die Reihenfolge" auf der Produktionsseite.

    
TomTom 08.03.2010 11:22
quelle

Tags und Links