SAX vs XmlTextReader - SAX en C #

Question

J'essaie de lire un document XML volumineux et je voulais le faire en morceaux, par opposition à la façon dont XmlDocument lit le fichier entier en mémoire. Je sais que je peux utiliser XmlTextReader pour le faire, mais je me demandais si quelqu'un avait déjà utilisé SAX pour .NET? Je sais que les développeurs Java ne jurent que par elle et je me demandais si cela valait la peine de l'essayer et, le cas échéant, quels en sont les avantages. Je cherche des précisions.

Answer 1

Si vous parlez de SAX pour .NET , le projet ne semble pas être maintenu. La dernière version date de plus de 2 ans. Peut-être qu'ils ont eu la perfection sur la dernière version mais je ne parierais pas dessus L'auteur, Karl Waclawek, semble avoir disparu du réseau.

En ce qui concerne SAX sous Java? Vous pariez que c'est génial. Malheureusement, SAX n’ayant jamais été développé en standard, tous les ports non-Java ont adapté une API Java à leurs propres besoins. Bien que DOM soit une API assez moche, elle a l'avantage d'avoir été conçue pour plusieurs langages et environnements, de sorte qu'elle est facile à implémenter en Java, C #, JavaScript, C, etc.

Answer 2

Si vous souhaitez simplement que le travail soit effectué rapidement, XmlTextReader existe à cet effet (dans .NET).

Si vous souhaitez apprendre un standard de facto (et disponible dans d’autres langages de programmation) qui soit stable et qui vous obligera à coder de manière très efficace et élégante, mais qui est également extrêmement flexible, recherchez SAX. Cependant, ne perdez pas votre temps à moins de créer des analyseurs syntaxiques XML hautement ésotériques. Recherchez plutôt des analyseurs que la prochaine génération d'analyseurs (tels que XmlTextReader) pour votre plate-forme particulière.

Ressources SAX
SAX a été écrit à l'origine pour Java et vous pouvez trouver le projet open source original, stable depuis plusieurs années, ici: http://sax.sourceforge.net/

Il existe un port C # du même projet ici (avec la documentation HTML dans le téléchargement source); c'est aussi stable: http://saxdotnet.sourceforge.net/

Si vous n'aimez pas l'implémentation C #, vous pouvez toujours recourir au référencement de DLL COM via COMInterop à l'aide de MSXML3 ou ultérieur: http://msdn.microsoft.com/en-us/library/ms994343.aspx

Des articles issus du monde Java mais qui illustrent probablement les concepts dont vous avez besoin pour réussir cette approche (il peut également y avoir un code source Java téléchargeable qui pourrait s'avérer utile et assez facile à convertir en C #):

• Produisez des documents XML volumineux, Partie 1 ( http: // www. .ibm.com / developerworks / xml / library / x-tipbigdoc.html )
• Produisez des documents XML volumineux, Partie 2 ( http: // www. .ibm.com / developerworks / xml / library / x-tipbigdoc2.html )
• Utilisez un filtre SAX pour manipuler les données ( http: // www. ibm.com/developerworks/xml/library/x-tipsaxfilter/ )

Ce sera une implémentation lourde. Je n'utilisais SAX que lorsque j'étais pré-NET, mais cela nécessite des techniques de codage assez avancées. À ce stade, cela ne vaut tout simplement pas la peine.

Concept intéressant pour un analyseur hybride
Ce fil décrit un analyseur hybride qui utilise .NET XmlTextReader pour implémenter un analyseur qui fournit une combinaison d’avantages DOM et SAX ...
http://bytes.com/groups/net-xml/178403- xmltextreader-versus-dom

Answer 3

Je pense qu’il n’ya aucun avantage à utiliser SAX au moins pour deux raisons:

1. SAX est un "push" model tandis que XmlReader est un analyseur syntaxique d'extraction doté de de nombreux avantages .
2. Être dépendant d'une bibliothèque tierce plutôt que d'utiliser une API .NET standard.

Answer 4

Personnellement, je préfère de loin le modèle SAX, car XmlReader comporte des pièges vraiment gênants qui peuvent causer des bogues dans votre code, ce qui pourrait faire en sorte que votre code ignore des éléments. La plupart du code serait structuré autour d'un modèle while (rdr.Read ()), mais si vous avez un "ReadString". ou " ReadInnerXml () " dans cette boucle, vous vous retrouverez à sauter des éléments à la prochaine itération.

Etant donné que SAX est basé sur des événements, cela ne ralentira jamais, car vous ne pouvez effectuer aucune opération qui entraînerait une recherche anticipée de votre analyseur.

Mon sentiment personnel est que Microsoft a inventé l'idée que le XmlReader est meilleur avec l'explication du modèle push / pull, mais je ne l'achète pas vraiment. Microsoft pense donc que vous n'avez pas besoin de créer une machine à états avec XmlReader, cela n'a aucun sens pour moi, mais de toute façon, c'est juste mon avis.