SAX vs XmlTextReader-SAX en C#

java

Question

XmlDocument leer un documento XML de gran tamaño y quería hacerlo en fragmentos en comparación con la forma en que XmlDocument lee todo el archivo en la memoria. 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 han jurado y me pregunto si vale la pena intentarlo y, de ser así, cuáles son los beneficios de su uso. Estoy buscando detalles.

Answer 1

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

1. SAX es un modelo "push" mientras que XmlReader es un analizador de extracción que tiene una serie de beneficios .
2. Depende de una biblioteca de terceros en lugar de utilizar una API .NET estándar.

Answer 2

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

En cuanto a SAX en Java? Usted apuesta, es genial. Desafortunadamente, SAX nunca se desarrolló como estándar, por lo que todos los puertos que no son Java han estado adaptando una API de Java para sus propias necesidades. Si bien DOM es una API bastante pésima, 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 3

Si solo desea hacer el trabajo rápidamente, XmlTextReader existe para ese fin (en .NET).

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

Recursos de SAX
SAX se escribió originalmente para Java, y puedes 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 la fuente); también es estable: http://saxdotnet.sourceforge.net/

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

Artículos que provienen del mundo de 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 resultar útil y puede ser fácil de convertir a C #):

• Salida de documentos XML grandes, Parte 1 ( http://www.ibm.com/developerworks/xml/library/x-tipbigdoc.html )
• Salida de documentos XML grandes, Parte 2 ( http://www.ibm.com/developerworks/xml/library/x-tipbigdoc2.html )
• Utilice un filtro SAX para manipular 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 .NET, pero requiere algunas técnicas de codificación bastante avanzadas. En este punto, simplemente no vale la pena el problema.

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

Answer 4

Personalmente, prefiero el modelo SAX ya que el XmlReader tiene algunas trampas realmente molestas que pueden causar errores en tu código que pueden hacer que tu código omita elementos. La mayoría del código se estructuraría en torno a un modelo while (rdr.Read ()), pero si tiene cualquier "ReadString" o "ReadInnerXml ()" dentro de ese ciclo, se encontrará omitiendo elementos en la siguiente iteración.

Como SAX está basado en un evento, esto nunca ocurrirá ya que no puede realizar ninguna operación que haga que su analizador busque anticipadamente.

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