Quali sono le differenze tra il XmlSerializer e BinaryFormatter

Question

Ho passato una buona parte del tempo la scorsa settimana a lavorare su serializzazione. Durante quel periodo ho trovato molti esempi che utilizzano sia la BinaryFormatter o XmlSerializer. Purtroppo, quello che non ho trovato sono stati gli esempi completo dettaglio le differenze tra i due.

La genesi della mia curiosità sta nel motivo per cui il BinaryFormatter è in grado di deserializzare direttamente ad un'interfaccia mentre il XmlSerializer non lo è. Jon Skeet in una risposta a " colata a più tipi (sconosciuto) in fase di esecuzione " fornisce un esempio di serializzazione binaria diretta ad un'interfaccia. Stan R. mi ha fornito i mezzi per realizzare il mio obiettivo utilizzando il XmlSerializer nella sua risposta alla domanda "XML oggetto deserializzazione di interfacciarsi ".

Al di là della evidente del BinaryFormatter utilizza la serializzazione binaria mentre il XmlSerializer utilizza XML Mi piacerebbe capire più a fondo le differenze fondamentali. Quando utilizzare uno o l'altro ed i pro ei contro di ciascuna.

Answer 1

La ragione un formattatore binario è in grado di deserializzare direttamente ad un tipo di interfaccia è perché quando un oggetto è originariamente serializzato in un flusso binario contenente metadati tipo e assemblaggio informazione è bloccato con i dati dell'oggetto. Ciò significa che quando il formattatore binario deserializza l'oggetto si conosce il tipo, costruisce l'oggetto giusto e si può quindi lanciare quella di un tipo di interfaccia che oggetto implementa.

Il serializzatore XML sul otherhand solo serializza a uno schema e serializza solo i campi pubblici e valori dell'oggetto e nessuna informazione di tipo altri allora che (ad esempio interfacce gli strumenti di tipo).

Ecco un buon posto, NET serializzazione , confrontando il BinaryFormatter , SoapFormatter , e XmlSerializer . Vi consiglio di guardare la tabella seguente, che, oltre al già citato serializzatori include il DataContractSerializer , NetDataContractSerializer e protobuf-net .

Answer 2

Solo per pesare in ...

La differenza evidente tra i due è "binario vs xml", ma lo fa andare molto più in profondità:

• campi (BinaryFormatter = bf) vs pubblici i membri (in genere le proprietà) (XmlSerializer = xs)
• tipo di metadati basato (bf) vs contratto-based (xs)
• Versione-fragile (bf) vs la versione ad elevata disponibilità (XS)
• "grafico" (bf) vs "albero" (xs)
• .NET specifico (bf) vs portatili (xs)
• opaco (bf) vs leggibili (xs)

Come una discussione del perché BinaryFormatter può essere fragile, vedi qui .

E 'impossibile discutere, che è più grande; tutto il tipo di metadati in BinaryFormatter può rendere più grande. E XmlSerializer può lavorare molto con la compressione come gzip.

Tuttavia, è possibile prendere i punti di forza di ciascuno; per esempio, Google ha open source il proprio formato di dati di serializzazione, "buffer di protocollo". Si tratta di:

• contratto-base
• portatile (vedi elenco di implementazioni )
• Versione-tolerant
• ad albero
• opaca (anche se ci sono strumenti per mostrare i dati quando combinato con un .proto)
• tipicamente " contratto prima ", ma alcune implementazioni consentono contratti impliciti sulla base di riflessione

Ma, soprattutto, si tratta di dati molto densi (nessun tipo di metadati, rappresentazione binaria pura, tag brevi, trucchi come base-7 codifica variante di lunghezza), e molto efficiente per processo (nessuna struttura xml complessa, nessun stringhe da abbinare a membri, ecc).

Potrei essere un po 'prevenuto; Io sostengo una delle implementazioni (tra cui alcuni adatto per C # /. NET), ma si noterà che non ho  legata alla qualsiasi specifica implementazione; il formato sta sotto i suoi meriti ;-p

Answer 3

Il serializzatore XML produce XML e anche uno schema XML (implicitamente). Produrrà XML conforme a questo schema.

Una conseguenza è che non sarà serializzare tutto ciò che non può essere descritto in XML Schema. Ad esempio, non v'è alcun modo per distinguere tra una lista ed un array in XML Schema, quindi lo schema XML prodotto dal serializzatore può essere interpretato in entrambi i modi.

serializzazione Runtime (che il BinaryFormatter fa parte) serializza i tipi .NET effettivi verso l'altro lato, quindi, se si invia un List<int>, l'altro lato avrà un List<int>.

Che ovviamente funziona meglio se l'altro lato è in esecuzione .NET.

Answer 4

Il XmlSerializer serialises il tipo leggendo tutte le proprietà del tipo che hanno sia un getter pubblico e un setter pubblico (e anche eventuali campi pubblici). In questo senso il XmlSerializer serializza / deserializza la "vista pubblica" dell'istanza.

Il formattatore binario, invece, serializza un tipo serializzando "interni" dell'istanza, cioè relativi campi. Tutti i campi che non sono contrassegnati come [NonSerialized] verranno serializzati al flusso binario. Il tipo stesso deve essere contrassegnato come [Serializable] come devono eventuali campi interni che sono anche da serializzare.

Answer 5

Credo che uno dei più importanti è che la serializzazione binario può serializzare i membri pubblici e privati, mentre l'altro funziona solo con quelli pubblici.

Qui, fornisce un confronto molto utile tra questi due in termini di dimensioni. Si tratta di una questione molto importante, perché si potrebbe inviare il vostro oggetto serializzato a un computer remoto.

http: //www.nablasoft.com/alkampfer/index.php/2008/10/31/binary-versus-xml-serialization-size/