DataContract Nome nodo matrice serializzatore 'd3p1'

Question

Qualcuno potrebbe dirmi cosa significa il nome del nodo "d3p1" in questo?

<ActionMessage> 
     <Data xmlns:d3p1="http://schemas.microsoft.com/2003/10/Serialization/Arrays"> 
      <d3p1:anyType i:type="Agreement"> 
</d3p1:anyType> 
     <d3p1:anyType i:type="Agreement"> shortened 

ho ricevuto molti "che sembra brutto" e "che cosa se i cambiamenti d3p1" commenti su questo la serializzazione di default nel mio progetto asp WebAPI. Dico che è leggibile anche a macchina. Ma sono curioso perché sembra così.

Ecco i dettagli, ho un verbo GET sul controller che restituisce un enumerabile di ActionMessage

public IEnumerable<ActionMessage> Get(Guid) 

ActionMessage non può essere un generico (se questo sarebbe nemmeno aiuto) come la lista conterrebbe azione messaggi di diversi tipi generici. "newagreement", "keychange", ecc.

Sarebbe come ActionMessage<NewAgreement> o ActionMessage<KeyChange> e molti altri. Non c'è modo di farlo nell'ottenere mentre get restituisce molti "tipi" di messaggi di azione. Al di fuori di una classe base o di un'interfaccia. OSSIA ActionMessage<IMessage> ma questi messaggi non hanno nulla in comune.

Ecco come appare ora il messaggio di azione.

public class ActionMessage 
{ 
    [DataMember] 
    public Status Status { get; set; } 
    [DataMember] 
    [XmlElement(ElementName = "Agreement")] 
    [XmlArrayItem(ElementName = "testnode")] 
    public List<object> Data { get; set; } 
    [DataMember] 
    public MessageTypes Type { get; set; } 
    [DataMember] 
    public Guid Id { get; set; } 
} 

Nota l'XML "problematico" deriva dalla proprietà data.

Pensieri? La leggibilità umana dell'XML dovrebbe essere importante? Devo passare attraverso il dolore di passare dal serializzatore datacontract al serializzatore xml? Questo probabilmente abiliterà gli attributi del nome dell'elemento, ma preferisco lasciare tutto questo vaniglia, e mentre potrei controllare completamente l'XML generato, ho davvero bisogno di, o mi interessa davvero?

Answer 1

Dopo aver affrontato questo problema sono giunto alla conclusione che generalmente è meglio essere il più espliciti possibile con i contratti di dati. In questo caso, dividerei List<object> Data in più elenchi espliciti, ad esempio List<Agreement> Agreements; List<KeyChange> KeyChanges; e così via. L'XML risultante potrebbe essere simile a questo:

<ActionMessage> 
    <Status>...</Status> 
    <Agreements> 
     <Agreement>...</Agreement> 
    </Agreements> 
    <KeyChanges/> 
    ... 
</ActionMessage> 

Alcuni degli elementi sarà vuota (è possibile configurare il serializzatore di omettere questi) ma ognuno è esplicito e facile da leggere, analizzare, e deserializzare. Ancora più importante, i consumatori dello schema sanno esattamente cosa aspettarsi.

c'è un'altra opzione, e cioè a definire una sorta di interfaccia che Agreement, KeyChange, ecc potrebbe implementare tutti (ad esempio 'IData') e cambiare List<object> Data a List<IData> Data. Ne risulterebbe un documento XML leggermente più carino, ma sarebbe necessario mantenere un elenco di tipi noti per garantire che tutte le implementazioni possano essere deserializzate. L'XML dovrebbe essere simile a questa:

<ActionMessage> 
    <Status>...</Status> 
    <Data> 
     <IData xsi:type="Agreement">..</IData> 
     <IData xsi:type="KeyChange">..</IData> 
    </Data> 
    <KeyChanges/> 
    ... 
</ActionMessage> 

Tuttavia, questo rende per la deserializzazione fragili e può causare problemi con l'ora/la compatibilità all'indietro dei messaggi.