DataContractSerializer vs XmlSerializer: wady i zalety każdego serializatora

85

Moja aplikacja komputerowa serializuje obiekty przy użyciu XmlSerializer. Zaproponowano mi DataContractSerializerzamiast tego wykorzystanie dźwigni .
W jakich scenariuszach powinienem używać DataContractSerializer?

Wielkie dzięki

Komentarze.
1. Wynikowy plik XML jest przechowywany lokalnie. Żadna inna aplikacja nie deserializuje obiektów z tego pliku XML.
2. Moja aplikacja działa z .NET Framework 3.5 SP1.

.net serialization Vitali Climenco
źródło
Zobacz także datacontract-vs-xmltype
nawfal

Odpowiedzi:

113

Dan Rigsby opublikował ostateczny post na ten temat - przeczytaj go!

XmlSerializer a DataContractSerializer (archiwum internetowe)

Mówi wszystko, co ma do powiedzenia, w bardzo przekonujący sposób.

W skrócie:

XmlSerializer:

  • istnieje od dawna
  • oznacza „rezygnację”; wszystko, co publiczne, jest serializowane, chyba że powiesz mu, aby tego nie robić ([XmlIgnore])

DataContractSerializer to:

  • nowy dzieciak w mieście
  • zoptymalizowany pod kątem szybkości (zwykle około 10% szybciej niż XmlSerializer)
  • „opt-in” - tylko rzeczy, które wyraźnie oznaczysz jako [DataMember]serializowane
  • ale coś oznaczone [DataMember]zostaną w odcinkach - czy to publiclubprivate
  • nie obsługuje atrybutów XML (ze względu na szybkość)
marc_s
źródło
2
@ Paul-SebastianManole: DataContractSerializer nie obsługuje atrybutów XML - ze względu na szybkość. O co tu chodzi?
marc_s
6
@ Paul-SebastianManole: jeśli twój źródłowy XML zawiera atrybuty elementów XML (takich jak <Customer Id="42"> ...), jedyną opcją jest użycie serializatora XML
marc_s
2
Może to być przydatne, zaczerpnięte z MSDN: Klasa XmlSerializer obsługuje znacznie węższy zestaw typów niż klasa DataContractSerializer, ale umożliwia znacznie większą kontrolę nad wynikowym kodem XML i obsługuje znacznie więcej standardu języka definicji schematu XML (XSD). Nie wymaga również żadnych deklaratywnych atrybutów w typach możliwych do serializacji ... Klasa XmlSerializer nie obsługuje typów kontraktów danych. MSDN .
Paul-Sebastian Manole
1
@OO: nie tylko opt-in, w .NET 3.5 SP1 i nowszych - ale dla mnie jest to nadal preferowany sposób robienia rzeczy. Pozwala ustawić właściwości, których w innym przypadku nie można ustawić (np. Kolejność serializacji, przestrzenie nazw i wiele więcej!)
marc_s
17
Największe ostrzeżenie dotyczące DataContractSerializer - podczas deserializacji dba o kolejność elementów i dyskretnie kończy się niepowodzeniem, jeśli nie są we właściwej kolejności. Imho, chyba że używasz dokładnie tych samych zespołów na obu końcach, czyni to niezwykle niebezpiecznym.
Pxtl