SAX vs XmlTextReader - SAX en C #

Question

Estoy intentando leer un documento XML grande y quería hacerlo en la forma de leer todo el archivo en la memoria de chunks vs XmlDocument . Sé que puedo usar XmlTextReader para hacer esto, pero me preguntaba si alguien ha usado SAX para .NET. Sé que los desarrolladores de Java lo confían y me preguntaba si vale la pena intentarlo y, de ser así, cuáles son los beneficios de usarlo. Estoy buscando detalles.

Answer 1

Si estás hablando de SAX para .NET , el proyecto no parece mantenerse. El último lanzamiento fue hace más de 2 años. Tal vez lo obtuvieron perfecto en el último lanzamiento, pero no apostaría por ello. El autor, Karl Waclawek, parece haber desaparecido de la red.

¿En cuanto a SAX bajo Java? Usted apuesta, es genial. Desafortunadamente, SAX nunca se desarrolló como estándar, por lo que todos los puertos que no son de Java han estado adaptando una API de Java para sus propias necesidades. Si bien DOM es una API bastante mala, tiene la ventaja de haber sido diseñada para múltiples idiomas y entornos, por lo que es fácil de implementar en Java, C #, JavaScript, C, et al.

Answer 2

Si solo desea terminar el trabajo rápidamente, XmlTextReader existe para ese propósito (en .NET).

Si desea aprender un estándar de facto (y disponible en muchos otros lenguajes de programación) que es estable y que lo obligará a codificar de manera muy eficiente y elegante, pero que también es extremadamente flexible, busque SAX. Sin embargo, no pierdas el tiempo a menos que vayas a crear analizadores XML altamente esotéricos. En su lugar, busque los analizadores que analizan la próxima generación (como XmlTextReader) para su plataforma en particular.

Recursos de SAX
SAX fue escrito originalmente para Java, y puede encontrar el proyecto de código abierto original, que se ha mantenido estable durante varios años, aquí: http://sax.sourceforge.net/

Aquí hay un puerto C # del mismo proyecto (con documentos HTML como parte de la descarga de origen); también es estable http://saxdotnet.sourceforge.net/

Si no le gusta la implementación de C #, siempre puede recurrir a hacer referencia a COM DLL a través de COMInterop utilizando MSXML3 o posterior: http://msdn.microsoft.com/en-us/library/ms994343.aspx

Artículos que provienen del mundo Java pero que probablemente ilustran los conceptos que necesita para tener éxito con este enfoque (también puede haber un código fuente de Java descargable que podría ser útil y puede ser lo suficientemente fácil de convertir a C #):

• Envíe documentos XML grandes, Parte 1 ( http: // www .ibm.com / developerworks / xml / library / x-tipbigdoc.html )
• Envíe documentos XML grandes, Parte 2 ( http: // www .ibm.com / developerworks / xml / library / x-tipbigdoc2.html )
• Use un filtro SAX para manipular los datos ( http: // www. ibm.com/developerworks/xml/library/x-tipsaxfilter/ )

Será una implementación engorrosa. Solo he usado SAX en mis días anteriores a la red, pero requiere algunas técnicas de codificación bastante avanzadas. En este punto, simplemente no vale la pena.

Concepto interesante para un analizador híbrido
Este hilo describe un analizador híbrido que utiliza .NET XmlTextReader para implementar un analizador que proporciona una combinación de beneficios de DOM y SAX ...
http://bytes.com/groups/net-xml/178403- xmltextreader-versus-dom

Answer 3

Creo que no hay beneficios al usar SAX al menos por dos razones:

1. SAX es un " empuje " model mientras XmlReader es un analizador de extracción que tiene una serie de beneficios .
2. Depender de una biblioteca de terceros en lugar de usar una API .NET estándar.

Answer 4

Personalmente, prefiero el modelo SAX, ya que XmlReader tiene algunas trampas realmente molestas que pueden causar errores en su código que podrían hacer que su código salte elementos. La mayoría del código se estructuraría alrededor de un modelo rdr.Read ()), pero si tiene algún " ReadString " o " ReadInnerXml () " dentro de ese bucle, se encontrará saltando elementos en la siguiente iteración.

Como SAX se basa en eventos, esto nunca sucederá, ya que no puede realizar ninguna operación que haga que su analizador busque más.

Mi opinión personal es que Microsoft ha inventado la idea de que XmlReader es mejor con la explicación del modelo push / pull, pero realmente no lo compro. Entonces, Microsoft cree que no es necesario crear una máquina de estados con XmlReader, eso no tiene sentido para mí, pero de todos modos, es solo mi opinión.