DataContractSerializer Vs XmlSerializer

Serializzatore…quale scegliere e perchè?

Diciamo, innanzitutto, che dal framework 3.0 abbiamo la possibilità di scegliere come serializzare un grafo di oggetti (che bello ora abbiamo l’imbarazzo della scelta T_T), ma in base a cosa scelgo? beh… ho fatto un pò di test ed ho evidenziato quelli che, dal mio punto di vista, potrebbero essere pregi e difetti dell’uno e dell’altro.Iniziamo rispettando i più anziani:

XmlSerializer:

  • Serializza tutte le property , tranne quelle che gli viene detto di ignorare (ricordate che lavora solo sulle property pubbliche)
  • Controllo completo sull'xml generato (posso scegliere quale property rendere un attribute e cosa un element)

DataContractSerializer:

  • Serializza solo quello che viene decorato come da serializzare (anche datamember privati)
  • può serializzare classi decorate con l'attributo [Serializable] (lo vedo un pregio se voglio usare questo serializzatore senza dover ridecorare tutte le mie classi,ma guardando l’xml generato…sembra quasi un difetto)
  • ho letto su internet che rende la serializzazione più veloce del 10% rispetto ad XmlSerializer ma sui test fatti da me siamo su un ordine leggermente diverso
    • su 1 elemento
      • DataContractSerializer 34ms 
      • XmlSerializer 204ms
    • su 900000 elementi (senza oggetti innestati)
      • DataContractSerializer 1863ms 
      • XmlSerializer 3750ms
    • su 900000 elementi (di cui 9000 con altri oggetti contenuti che contengono a loro volta altri 3000 oggetti)
      • DataContractSerializer 2458ms 
      • XmlSerializer 3691ms
  • Crea solo element e non attribute (su questo voglio indagare meglio, ma finora non ho avuto modo di fargli creare attribute), l’unico controllo che ho sui membri decorati con [DataMember] sono “IsRequired, Name, Order, DefaultValue”

 

considerando il divario prestazionale che si è creato tra le due serializzazioni, direi che se devo scegliere come serializzare, indipendentemente dal modo (nodi ed attributi), beh…non ho molti dubbi su cosa scegliere (anche se non vi nascondo che voglio fare ancora qualche test, magari con un grafo più complesso)

viceversa se voglio che il mio xml abbia una struttura ben precisa (magari che rispecchi uno Schema XSD contenente anche degli attributi) beh devo adattare il mio sviluppo e le mie classi all’utilizzo con XmlSerializer perchè è lui la scelta migliore

Se non mi preoccupano ne prestazioni ne schema, sceglierei (personalmente) DataContractSerializer perchè le decorazioni necessarie rendono più chiaro, per chi guarda le nostre classi, cosa intendiamo esporre

 

sperando come sempre di essere stato utile a qualcuno attendo eventuali vostri rimproveri o suggerimenti

E.

Published 6 Jul 2010 13:22 da Nezumi
Inserito sotto: ,

Commenti

Wednesday, July 07, 2010 11:08 AM da Salvatore Sorrentino

# re: DataContractSerializer Vs XmlSerializer

Salve! Molto interessante!

Volevo chiederti se hai studiato il caso in cui gli oggetti siano stati creati tramite Entity Data Model o LINQ to SQL classes a partire da un database.

Salvatore

Wednesday, July 07, 2010 9:21 PM da Nezumi

# re: DataContractSerializer Vs XmlSerializer

hmmm beh in realtà sui test che ho fatto mi sono interessato solo di serializzazione.

la tua domanda viene fuori forse da una valutazione che vorresti fare della latenza dovuta al recupero e creazione dell'istanza degli oggetti?

Thursday, July 08, 2010 9:32 AM da Salvatore Sorrentino

# re: DataContractSerializer Vs XmlSerializer

Si. Vorrei quantificare questi effetti (se ci sono). Da un punto di vista più generale, poi, mi chiedo anche se sia corretto serializzare oggetti "complessi" creati da Entity Data Model o LINQ to SQL o sia meglio utilizzare oggetti intermedi da noi costruiti. Mi piacerebbe sentire la tua opinione in merito.

Thursday, July 08, 2010 3:15 PM da Nezumi

# re: DataContractSerializer Vs XmlSerializer

Beh...anche a me sarebbe sempre piaciuto far viaggiare tra i vari tier gli EntityObject, perché così non devo stare lì a crearmi altre classi, ma i tempi richiesti per serializzarlo rispetto ad un POCO (o un DTO) sono nettamente diversi.siamo sull'ordine del 1000% (test miei però, che sono tutt'altro che il verbo) ma questo perché l'entityObj si porta dietro un sacco di altre informazioni che tu nel tuo oggetto ad hoc non useresti (almeno credo :-D ), però poi si presentano tante altre problematiche (come la gestione dell'ObjectState per esempio)... insomma se posso dire come la penso: finché l'oggetto viaggia tra layer logici, EntityObject per tutta la vita, così un sacco di dinamiche le lascio ad E.F. , ma se si deve spostare fisicamente, allora sceglierei i DTO, che sono molto più agili

Friday, July 09, 2010 9:57 AM da Salvatore Sorrentino

# re: DataContractSerializer Vs XmlSerializer

Daccordissimo. Grazie della risposta!