SAX vs XmlTextReader - SAX en C#

Question

Estoy intentando leer un documento XML de gran tamaño y quería hacerlo en fragmentos en comparación con la forma de XmlDocument de leer 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

Si habla de SAX for .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 2

creo que no hay beneficios utilizando SAX al menos por dos razones:

1. SAX es un modelo "push", mientras que XmlReader es un analizador tirón que tiene a number of benefits.
2. Depende de una biblioteca de terceros en lugar de utilizar una API .NET estándar.

Answer 3

Si solo desea hacer el trabajo rápidamente, el XmlTextReader existe para ese propósito (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 SAX
SAX fue escrito originalmente para Java, y se puede encontrar el proyecto original de código abierto, que se ha mantenido estable durante varios años, aquí: http://sax.sourceforge.net/

hay un puerto de C# de el mismo proyecto aquí (con documentos HTML como parte de la descarga de la fuente); También es estable: http://saxdotnet.sourceforge.net/

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

los artículos que vienen del mundo Java, pero que probablemente ilustrar los conceptos que necesita para tener éxito con este enfoque (también puede haber código fuente de Java descargable que podría ser útil y puede ser bastante fácil de convertir a C#):

• grande de la salida de documentos XML, Parte 1 (http://www.ibm.com/developerworks/xml/library/x-tipbigdoc.html)
• grandes documentos XML de salida, Parte 2 (http://www.ibm.com/developerworks/xml/library/x-tipbigdoc2.html)
• utilizar un filtro SAX para manipular los datos (http://www.ibm.com/developerworks/xml/library/x-tipsaxfilter/)

Será una aplicación engorroso. 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 utiliza el XMLTextReader .NET para implementar un programa de análisis que ofrece 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 eventos, esto nunca se ejecutará ya que no puede realizar ninguna operación que pueda hacer que su analizador busque por adelantado.

Mi sensación personal es que Microsoft ha inventado la noción de que el 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.