XmlTextReader vs. XDocument

Question

Je suis en mesure d'analyser le XML en .NET. J'ai maintenant le choix entre au moins XmlTextReader y XDocument . Y a-t-il des comparaisons entre ces deux-là (ou tout autre analyseur XML contenu dans le framework) ?

Peut-être cela pourrait-il m'aider à prendre une décision sans avoir à les essayer tous les deux en profondeur.

Les fichiers XML sont censés être assez petits, la vitesse et l'utilisation de la mémoire sont un problème mineur par rapport à la facilité d'utilisation :-)

(Je vais les utiliser à partir de C# et/ou IronPython).

Gracias.

Answer 1

Si vous préférez lire tout ce qui est en mémoire, utilisez XDocument . Cela rendra votre vie beaucoup plus facile. LINQ to XML est un joli API.

Utilisez un XmlReader (par exemple XmlTextReader ) si vous devez gérer énorme des fichiers XML en continu, en gros. C'est une API beaucoup plus pénible, mais elle permet le streaming (c'est-à-dire qu'elle ne traite les données que lorsque vous en avez besoin, ce qui vous permet de parcourir un énorme document et de n'en avoir qu'une petite partie en mémoire à la fois).

Il existe cependant une approche hybride : si vous avez un énorme document composé de petits éléments, vous pouvez créer un XElement d'un XmlReader positionné au début de l'élément, traiter l'élément à l'aide de LINQ to XML, puis déplacer la balise XmlReader sur l'élément suivant et recommencez.

Answer 2

XmlTextReader est en quelque sorte déprécié, ne l'utilisez pas.

1. De msdn blogs par XmlTeam

   Xml efficace Partie 1 : Choisir la bonne API

   Évitez d'utiliser XmlTextReader . Il contient un certain nombre de bogues qui ne pouvaient pas être corrigés sans casser les applications existantes qui l'utilisent déjà.

   Le monde a évolué, et vous ? Les API Xml que vous devriez éviter d'utiliser.

   Les API obsolètes sont faciles à utiliser puisque le compilateur aide à les identifier, mais il y a deux autres API que vous devriez éviter d'utiliser - à savoir XmlTextReader y XmlTextWriter . Nous avons trouvé un certain nombre de bogues dans ces classes que nous ne pouvions pas corriger sans casser les applications existantes. La solution la plus simple serait de déprécier ces classes et de demander aux gens d'utiliser des API de remplacement à la place. Malheureusement, ces deux classes ne peuvent pas être marquées comme obsolètes car elles font partie de la norme ECMA-335 (Common Language Infrastructure) ( http://www.ecma-international.org/publications/standards/Ecma-335.htm ) - le fichier compagnon CLILibrary.xml qui fait partie de la Partition IV).

   La bonne nouvelle est que, même si ces classes ne sont pas dépréciées, il existe déjà des API de remplacement dans .NET Framework et il est relativement facile de passer à ces API. Tout d'abord, il est nécessaire de trouver les endroits où XmlTextReader ou XmlTextWriter est utilisé (malheureusement, il s'agit d'une étape manuelle). Maintenant, toutes les occurrences de XmlTextReader doit être remplacé par XmlReader et toutes les occurrences de XmlTextWriter doit être remplacé par XmlWriter (notez que XmlTextReader provient de XmlReader y XmlTextWriter provient de XmlWriter l'application peut donc déjà les utiliser, par exemple comme paramètres formels). La dernière étape consiste à modifier la façon dont l'application XmlReader / XmlWriter sont instanciés - au lieu de créer directement le lecteur/écrivain, il est nécessaire d'utiliser la méthode statique de l'usine. .Create() présents sur les deux XmlReader y XmlWriter APIs.

2. De plus, intellisense dans Visual Studio ne liste pas XmlTextReader sous l'espace de noms System.Xml. La classe est définie comme :

   [EditorBrowsable(EditorBrowsableState.Never)]
   public class XmlTextReader : XmlReader, IXmlLineInfo, IXmlNamespaceResolver

En XmlReader.Create les méthodes d'usine renvoient d'autres interne implémentations de la classe abstraite XmlReader en fonction des paramètres passés.

---

Pour une API de diffusion en continu (c'est-à-dire qui ne charge pas tout en mémoire), utilisez XmlReader via XmlReader.Create méthode.

Pour une API plus facile à utiliser, optez pour l'option XDocument alias LINQ To XML. Trouvez XDocument vs XmlDocument aquí y aquí .