2009-04-02 13 views
8

Per ottenere maggiore controllo sulla serializzazione, ho convertito una classe da [DataContract] a [Serializable], implementando sia GetObjectData che il costruttore speciale deserializzante. Quando faccio questo, l'XML emesso ora ha informazioni sul tipo applicate a tutti gli elementi. Non voglio questa informazione superflua, e mi chiedo come informare il serializzatore per non emetterlo.Quando si utilizza ISerializable con DataContractSerializer, come posso impedire al serializzatore di emettere informazioni sul tipo?

Ecco il codice di esempio che utilizza [DataContract]:

[DataContract(Namespace = "")] 
class Test 
{ 
    public Test() { } 
    [DataMember] 
    public Nullable<int> NullableNumber = 7; 
    [DataMember] 
    public int Number = 5; 

    public static void Go() 
    { 
     var test = new Test(); 
     var dcs = new DataContractSerializer(typeof(Test)); 
     using (var s = new StreamWriter("test.xml")) 
     { 
      dcs.WriteObject(s.BaseStream, test); 
     } 
    }   
} 

Emette il seguente codice XML (nota nessun tipo informazioni Nullable Numero e Numero - questo è il risultato desiderato):

<Test xmlns:i="http://www.w3.org/2001/XMLSchema-instance"> 
    <NullableNumber>7</NullableNumber> 
    <Number>5</Number> 
</Test> 

Se modifico il codice precedente come segue (aggiunta [Serializable],: ISerializable, ei due metodi di serializzazione):

[Serializable] 
class Test : ISerializable 
{ 
    public Test() { } 
    public Nullable<int> NullableNumber = 7; 
    public int Number = 5; 

    public static void Go() 
    { 
     var test = new Test(); 
     var dcs = new DataContractSerializer(typeof(Test)); 
     using (var s = new StreamWriter("test.xml")) 
     { 
      dcs.WriteObject(s.BaseStream, test); 
     } 
    }   
    public Test(SerializationInfo info, StreamingContext context) 
    { 
     NullableNumber = info.GetInt32("NullableNumber"); 
     Number = info.GetInt32("Number"); 
    } 

    public void GetObjectData(SerializationInfo info, StreamingContext context) 
    { 
     info.AddValue("NullableNumber", NullableNumber); 
     info.AddValue("Number", Number); 
    } 
} 

Ora emette il seguente codice XML. Notare le informazioni sul tipo (i: type = "x: int") aggiunte a ciascun elemento.

<Test xmlns="http://schemas.datacontract.org/2004/07/XMLSerialization" xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns:x="http://www.w3.org/2001/XMLSchema"> 
    <NullableNumber i:type="x:int" xmlns="">7</NullableNumber> 
    <Number i:type="x:int" xmlns="">5</Number> 
</Test> 

Perché lo fa? Come faccio a impedirgli di farlo?

Grazie!

+0

Grazie per la domanda, perché ha risolto la mia domanda :-) Per quanto riguarda "perché" - nel primo esempio c'era una garanzia che ogni voce è un campo, quindi è possibile ottenere il tipo di campo solo cercando al tipo 'Test'. Nel secondo caso ** tu ** hai il controllo, quindi quelle voci non devono necessariamente essere campi, potresti scrivere/leggere solo dati casuali. – astrowalker

risposta

0

Avete bisogno dello ISerializable qui? Qual è stato il normale DataContractSerializer non ti ha dato? Se torni indietro, dovrebbe funzionare bene.

In pratica, implementando la serializzazione personalizzata, i dati non sono più basati su contratto, quindi lo ha per includere queste informazioni aggiuntive per garantire che sia in grado di capirle in seguito.

Quindi: c'è un motivo per implementare ISerializable in questo caso?

+0

Ho rifilato l'esempio per semplificare la domanda. Ho bisogno di serializzazione personalizzata per ragioni che non mostro qui. – Eric

+0

Di (lunga lista) di ragioni per cui ho bisogno di serializzazione personalizzata, il più grande è che ho bisogno di generare condizionatamente determinate proprietà basate su altre informazioni. – Eric

+1

Non capisco il tuo commento su "esso" deve "includere queste informazioni extra". In effetti, il primo esempio XML sopra deserializza perfettamente con il deserializzatore [Serializable], quindi il deserializzatore non ha bisogno di questo tipo di informazioni. – Eric

Problemi correlati