2010-04-06 48 views
6

mi sono imbattuto in questa domanda Transcender:Qual è la differenza tra la [OptionalField] e [NonSerialized]

Cosa si dovrebbe applicare a un campo se il suo valore non è richiesto durante la deserializzazione?

Me = [NonSerialized], RISPOSTA = [OptionalField]

La mia reazione istintiva era NonSerialised ma Transcender dice che sono sbagliate. Ho una buona idea su cosa guardare per quanto riguarda l'attributo [Nonseralized], ma comunque mi piacerebbe molto chiarire.

Per quanto posso dire, il primo ha una relazione con i conflitti di versione tra le versioni più recenti e precedenti dello stesso assembly. Quest'ultimo è più interessato a non serializzare un campo FULLSTOP. C'è qualcos'altro che potrebbe mettere questi due a parte? MSDN in realtà non dice molto su questo dato che entrambi sono usati su BinaryFormatters e SoapFormatter con XMLFormatter usando XMLIgnoreAttribute.

La mia seconda domanda è possibile combinare uno dei due attributi? Devo ancora usarli.

Basta lanciare questo fuori là, ma la mia risposta ha qualcosa a che fare con il modo in cui [OnDeserialized] e l'interfaccia IdeserilizationCallback è implementata?

UPDATE:

So che attributo campo facoltativo non serializzare il valore detenuto da un membro di dati, ma non sarà nemmeno NonSerialized puntate il membro dati o il suo valore.

+0

Solo per completezza - per tutto ciò che riguarda lo spazio di archiviazione (vale a dire dove il controllo delle versioni diventa un problema), 'BinaryFormatter' potrebbe non essere una buona scelta.Vedo * un sacco * di persone con problemi quando si percorre questa strada. –

+0

Grazie Marc, sono a conoscenza di questo problema, ma ho solo bisogno di capire bene questi due attributi per quanto riguarda l'esame 70-536. – IbrarMumtaz

risposta

6

Questi due attributi vengono utilizzati per i lati opposti dell'equazione di serializzazione.

Quando si utilizza [NonSerialized], si sta dicendo "questo campo non deve essere serializzato affatto" - quindi è più di un attributo "tempo di salvataggio". Fondamentalmente, stai dicendo che il campo non ha importanza per lo stato serializzato dell'oggetto.

Quando si utilizza [OptionalField], d'altra parte, si sta ancora per serializzare il campo. Tuttavia, se il campo è manca allo tempo di lettura (quando lo stream è deserializzato in un oggetto), quindi non verrà sollevata alcuna eccezione. Questo attributo è concepito per consentire di aggiungere un nuovo campo a un tipo serializzabile esistente, senza compromettere la compatibilità. Le versioni precedenti dell'oggetto (che mancano in quel campo) verranno deserializzate normalmente.

+0

grazie, questo è quello che avevo in mente, solo che potrebbe esserci qualcos'altro che potrei mancare .......:) – IbrarMumtaz

+0

@IbrarMumtaz: No - la differenza è nelle tue intenzioni. [Campo opzionale] suggerisce ancora che il campo ha un effetto sullo stato, ma [NotSerialized] significa davvero che il campo è qualcosa che non dovrebbe essere lì, non importa quale ... –

+0

'[NonSerialized]' può anche significare "questo campo si riferisce ad un oggetto che non può essere serializzato, quindi avremmo ottenuto un'eccezione se provassimo a serializzarlo ". –

1

Solo giocando fuori la lingua inglese, non richiesto e opzionale significano la stessa cosa in questo caso.

Per la tua prima domanda, l'hai praticamente inchiodato sulla testa. [OptionalField] fondamentalmente consente alle serializzazioni precedenti di essere compatibili con le definizioni più recenti. [NonSerialized] significa che non lo troverai nei dati serializzati.

Date le differenze, non riesco a immaginare perché avresti messo entrambi su un singolo campo ma direi che il compilatore si lamenterebbe.

+0

Il compilatore non darebbe due fischi. Il * runtime * potrebbe non piacere (non l'ho provato). –

+0

Non useresti mai entrambi, solo uno o l'altro, la domanda è quale? – IbrarMumtaz

Problemi correlati