2010-07-13 21 views
10

Acabo de enterarme de la clase XmlSerializer en .Net. Antes siempre había analizado y escrito mi XML utilizando las clases estándar. Antes de sumergirme en esto, me pregunto si hay algún caso en el que no sea la opción correcta.¿Alguna razón para no usar XmlSerializer?

EDITAR: Por clases estándar quiero decir XmlDocument, XmlElement, XmlAttribute ... etc.

+3

¿Qué 'clases estándar'? Esta pregunta necesita aclaración. –

+1

@DDavies: Creo que quiere decir con XmlDocument, XmlElement, XmlAttribute, etc. ... es decir. las clases de XML compatibles con los estándares W3C. – jrista

Respuesta

11

existen muchas limitaciones cuando se utiliza el XmlSerializer:

  • Debe tener una público sin parámetros constructor (como se ha mencionado por idlewire en los comentarios, que no tiene que ser público)
  • propiedades públicas sólo son tipos de interfaz en serie
  • no se pueden serializar
  • y algunos otros ...

Estas limitaciones a menudo obligan a tomar ciertas decisiones de diseño que no son las que le han hecho en otras situaciones ... y una herramienta que le obliga a tomar decisiones de diseño malos por lo general no es una buena cosa;)

Dicho esto, puede ser muy útil cuando necesita una forma rápida de almacenar objetos simples en formato XML. También me gusta el hecho de que tienes un control bastante bueno sobre el esquema generado.

+0

Tenga en cuenta que el constructor sin parámetros no necesita ser público. privado e interno también funcionarán. – idlewire

+0

@idlewire, tienes razón, nunca me di cuenta de eso antes. Sin embargo, sospecho que solo funcionará cuando se ejecute con plena confianza ... –

4

puedo encontrar los principales inconvenientes de la XmlSerializer son:

1) Para los gráficos de objetos complejos que implican colecciones, a veces es difícil de conseguir exactamente el esquema XML que desee utilizando los atributos de control de serialización.

2) Si cambia las definiciones de clase entre una versión de la aplicación y la siguiente, sus archivos serán ilegibles.

+4

# 2 es el más grande que encuentro que muchos programadores tienen miedo de –

+0

@ neil-n: ¡Definitivamente! – Mau

+1

Todavía no es tan frágil como 'BinarySerializer' –

5

Bueno, no le da tanto control sobre la salida, obviamente. Personalmente, encuentro que LINQ to XML hace que sea lo suficientemente fácil escribir esto a mano que estoy contento de hacerlo de esa manera, al menos para proyectos razonablemente pequeños. Si usa .NET 3.5 o 4 pero no utiliza LINQ to XML, investíguelo de inmediato: es mucho mucho mejor que el antiguo DOM.

A veces es bueno poder controlar la serialización y la deserialización ... especialmente cuando cambia el diseño de sus datos. Si no estás en esa situación y no anticipas estar en ella, entonces la serialización XML incorporada probablemente estaría bien.

EDITAR: Yo no piensa La serialización XML admite la construcción de tipos genuinamente inmutables, mientras que esto es obviamente factible desde la construcción manual. Como soy fanático de la inmutabilidad, definitivamente es algo que me preocupa. Si implementa IXmlSerializable, creo que puede conformarse con inmutabilidad pública, pero aún tiene que ser mutable de forma privada. Por supuesto, podría estar equivocado, pero vale la pena verificarlo.

+0

¿Podría aclarar un poco qué quiere decir con decir que es un fan de la inmutabilidad? ¿Cuál es su estrategia general para tratar la serialización de XML? –

+2

@Dmitry: me parece que cuando mis tipos son inmutables, el código es más fácil de razonar y el multihilo es más simple. Para la serialización XML, a menudo termino escribiendo mi propio código ToXElement y FromXElement manualmente. Rara vez es difícil, y terminas teniendo un control total sobre lo que se genera. –

0

Thera hay algunos escenarios.

  • Tiene que tratar con MUCHOS datos XML, el serializador puede superponerse a su memoria. Lo tuve una vez para un esquema simple que contenía un volcado de base de datos para 2000 o más tablas. Solo un puñado de clases, pero al final la serialización no funcionó. Tuve que usar un analizador de transmisión SAX.

Además de eso, no veo ninguna en circunstancias normales. Es una forma mucho más fácil de tratar con el Serializador XML que utilizar el analizador de nivel inferior, especialmente para datos más complejos.

5

El XmlSerializer puede ahorrarle muchos problemas si regularmente serializa y deserializa los mismos tipos, y si necesita que las representaciones serializadas de esos tipos sean consumibles por diferentes plataformas (es decir, Java, Javascript, etc.) I recomendamos usar XmlSerializer siempre que pueda, ya que puede aliviar una cantidad considerable de molestias tratando de gestionar la conversión de un gráfico de objetos a XML usted mismo.

Existen algunos casos en los que el uso de XmlSerializer no es el mejor enfoque. Aquí hay algunos casos:

  • cuando se necesita de forma rápida, sólo avance procesar grandes volúmenes de datos XML
    • utilizar un XmlReader lugar
  • Cuando necesite realizar búsquedas repetidas dentro de un documento xml con XPath
  • Cuando la estructura del documento xml es bastante arbitraria, y no se ajusta con regularidad a un modelo de objeto conocido
  • Cuando el XmlSeri alizer impone requisitos que no satisfacen sus mandatos diseño:
    • No lo utilice cuando no se puede tener un constructor público predeterminado
    • No puede utilizar los atributos de serializador XML para definir variantes de XML y elemento nombres de atributos para ajustarse al esquema XML necesario
+0

+1 para reunir el argumento size y XmlReader como alternativa – Abel

-1

cuando se quiere transmitir gran cantidad de datos y usted tiene recursos muy limitados.

2

Sí, personalmente uso la serialización automática de XML, aunque utilizo DataContractSerializer inicialmente traído por WCF (la capacidad de serializar tipos sin atributos es muy útil) ya que no incrusta tipos allí. Por supuesto, por lo tanto, necesita saber el tipo de objeto que está deserializando al volver a cargarlo.

El gran problema es que también es difícil serializar atributos sin implementar IXmlSerializable en el tipo de datos que desee. escribirse así, o exponiendo algunos otros tipos que el serializador puede manejar de forma nativa.

Supongo que el mayor problema con esto es que no se pueden serializar las interfaces automáticamente, porque el DCS quiere poder construir instancias nuevamente cuando reciba el XML de nuevo. Sin embargo, las interfaces de colección estándar son compatibles de forma nativa.

Con todo, he encontrado que la ruta de DCS es la más rápida y sin dolor.

Como alternativa, también podría investigar el uso de Linq a XML para leer y escribir el XML si desea un control total, pero de todos modos tendrá que procesar los tipos miembro por miembro.

He estado mirando eso recientemente (habiéndolo evitado como la peste porque no pude ver el punto) después de haber leído sobre ello el acceso temprano del nuevo libro de Jon Skeet. Tengo que decir que estoy muy impresionado con lo fácil que es trabajar con XML.

1

He usado XmlSerializer mucho en el pasado y probablemente continúe usándolo. Sin embargo, la mayor dificultad ya se mencionó anteriormente:

Las restricciones en el serializador (como la restricción a miembros públicos) 1) imponen restricciones de diseño en la clase que no tienen nada que ver con su función principal, o 2) forzar un aumento en la complejidad al trabajar alrededor de estas restricciones.

Por supuesto, otros métodos de serialización Xml también aumentan la complejidad.

Así que supongo que mi respuesta es que no hay una respuesta correcta o incorrecta que se adapte a todas las situaciones; Elegir un método de serialización es solo una consideración de diseño entre muchos otros.

Cuestiones relacionadas