DataContractSerializer vs XmlSerializer: pros y contras de cada serializador

84

Mi aplicación de escritorio serializa objetos usando XmlSerializer. En su lugar, me sugirieron aprovechar DataContractSerializer.
¿En qué escenarios debería utilizar DataContractSerializer?

Muchas gracias

Comentarios.
1. El archivo XML de salida se almacena localmente. Ninguna otra aplicación deserializa objetos de ese archivo XML.
2. Mi aplicación se ejecuta con .NET Framework 3.5 SP1.

.net serialization Vitali Climenco
fuente
Ver también datacontract-vs-xmltype
nawfal

Respuestas:

112

Dan Rigsby tiene la publicación definitiva sobre esto: ¡lee!

XmlSerializer frente a DataContractSerializer (archivo web)

Dice todo lo que hay que decir, y de una manera muy convincente.

En breve:

XmlSerializer:

  • ha existido durante mucho tiempo
  • es "optar por no participar"; todo lo público se serializa, a menos que usted le diga que no lo haga ([XmlIgnore])

DataContractSerializer es:

  • el chico nuevo en la ciudad
  • optimizado para la velocidad (aproximadamente un 10% más rápido que XmlSerializer, normalmente)
  • "opt-in": solo [DataMember]se serializarán los elementos que marque específicamente
  • pero todo lo marcado con [DataMember]se serializará, ya sea publicoprivate
  • no admite atributos XML (por razones de velocidad)
marc_s
fuente
2
@ Paul-SebastianManole: DataContractSerializer no admite atributos XML, por razones de velocidad. ¿Qué elaborar?
marc_s
6
@ Pablo-SebastianManole: si su fuente XML contiene atributos de elementos XML (como <Customer Id="42"> ...) entonces usted es la única opción es el uso de la serializador XML
marc_s
2
Esto podría ser útil, tomado de MSDN: la clase XmlSerializer admite un conjunto de tipos mucho más estrecho que la clase DataContractSerializer, pero permite mucho más control sobre el XML resultante y admite mucho más del estándar XML Schema Definition Language (XSD). Tampoco requiere ningún atributo declarativo en los tipos serializables ... La clase XmlSerializer no admite tipos de contrato de datos. MSDN .
Paul-Sebastian Manole
1
@OO: no solo opt-in, en .NET 3.5 SP1 y versiones posteriores, sino que para mí, sigue siendo la forma preferida de hacer las cosas. Le permite establecer propiedades que de otro modo no se pueden establecer (como el orden de serialización, espacios de nombres y mucho más)
marc_s
17
La mayor advertencia sobre DataContractSerializer: al deserializar, se preocupa por el orden de los elementos y falla silenciosamente si no están en el orden correcto. En mi humilde opinión, a menos que esté utilizando exactamente los mismos ensamblajes en ambos extremos, esto lo hace inutilizablemente peligroso.
Pxtl