2010-04-06 15 views
6

ich auf diese Frage auf transcender kam:Was ist der Unterschied zwischen dem [OptionalField] und [NonSerialized]

Was sollten Sie auf ein Feld anwenden, wenn ihr Wert nicht während der Deserialisierung wird benötigt?

Me = [NonSerialized] ANTWORT = [OptionalField]

Mein Bauch Reaktion war NonSerialised aber Transcender sagt, ich bin falsch. Ich habe eine gute Idee, worauf man achten sollte, wenn es um das Attribut [Nonseralized] geht, aber ich würde es trotzdem gerne klären.

Soweit ich feststellen kann, hat der ehemalige eine Beziehung mit Versionskonflikten zwischen neueren und älteren Versionen der gleichen Baugruppe. Letzteres beschäftigt sich mehr damit, ein Feld FULLSTOP nicht zu serialisieren. Gibt es noch etwas, das diese beiden auseinander bringen könnte? MSDN sagt nicht wirklich viel darüber, da beide in den BinaryFormatters und SoapFormatter mit dem XMLFormatter mit dem XMLIgnoreAttribute verwendet werden.

Meine zweite Frage ist, können Sie eines der beiden Attribute mischen und abgleichen? Ich muss sie noch benutzen.

Ich werfe nur dieses hier raus, aber hat meine Antwort etwas damit zu tun, wie [OnDeserialized] und die IdeerilizationCallback-Schnittstelle implementiert ist?

UPDATE:

Ich weiß, dass optionales Feld Attribut den Wert von einem Datenelement gehalten nicht serialisiert aber NonSerialized wird das Datenelement oder seinen Wert nicht einmal serialise.

+0

Nur der Vollständigkeit halber - für alles, was mit Speicher (d. H. Wo Versionierung ein Problem wird), ist "BinaryFormatter" möglicherweise keine gute Wahl.Ich sehe * viele * Leute mit Problemen, wenn sie diesen Weg gehen. –

+0

Danke Marc, ich bin von diesem Problem, aber ich muss nur ein gutes Verständnis dieser beiden Attribute bekommen, soweit es die Prüfung 70-536 betrifft. – IbrarMumtaz

Antwort

6

Diese beiden Attribute werden für entgegengesetzte Seiten der Serialisierungsgleichung verwendet.

Wenn Sie [NonSerialized] verwenden, sagen Sie "dieses Feld sollte überhaupt nicht serialisiert werden" - so ist es eher ein "Zeit sparen" -Attribut. Im Grunde sagen Sie, dass dieses Feld für den serialisierten Zustand des Objekts keine Rolle spielt. Wenn Sie [OptionalField] verwenden, werden Sie das Feld weiterhin serialisieren. Wenn das Feld jedoch fehlt um lesen Sie Zeit (wenn der Stream in einem Objekt deserialisiert wird), wird keine Ausnahme ausgelöst. Mit diesem Attribut können Sie einem vorhandenen Serialisierungstyp ein neues Feld hinzufügen, ohne die Kompatibilität zu beeinträchtigen. Ältere Versionen des Objekts (in denen dieses Feld fehlt) werden normalerweise deserialisiert.

+0

danke, das ist, was ich im Sinn hatte, ich nur tght da könnte etwas anderes sein, dass ich vermisse .......:) – IbrarMumtaz

+0

@IbrarMumtaz: Nein - der Unterschied liegt in Ihrer Absicht. [OptionalField] schlägt immer noch vor, dass das Feld einen Einfluss auf den Zustand hat, aber [NotSerialized] bedeutet wirklich, dass das Feld etwas ist, das einfach nicht da sein sollte, egal was ... –

+0

'[NonSerialized]' kann sogar bedeuten "das Das Feld bezieht sich auf ein Objekt, das nicht serialisiert werden kann, daher erhalten wir eine Ausnahme, wenn wir versuchen, es zu serialisieren. " –

1

Ausspielen nur die englische Sprache, nicht und optional das Gleiche bedeuten in diesem Fall nicht erforderlich.

Für Ihre erste Frage haben Sie es ziemlich auf den Kopf genagelt. [OptionalField] ermöglicht grundsätzlich ältere Serialisierungen mit neueren Definitionen kompatibel zu sein. [NonSerialized] bedeutet, dass Sie es in den serialisierten Daten nicht finden werden.

Angesichts der Unterschiede kann ich mir nicht vorstellen, warum Sie beide auf ein einzelnes Feld setzen würden, aber ich würde vermuten, dass der Compiler sich beschweren würde.

+0

Der Compiler würde nicht zwei Schreie geben. Die * Laufzeit * mag es vielleicht nicht (ich habe es nicht versucht). –

+0

Sie würden nie beide verwenden, nur die eine oder andere Frage ist welche? – IbrarMumtaz

Verwandte Themen