XmlTextReader против XDocument - программирование

Я могу анализировать XML в .NET. Теперь у меня есть выбор между по крайней мере XmlTextReader и XDocument. Существуют ли какие-либо сравнения между этими двумя (или любыми другими анализаторами XML, содержащимися в структуре)?

Может быть, это может помочь мне решить, не пытаясь их обоим.

Ожидается, что файлы XML будут довольно небольшими, скорость и использование памяти будут незначительной проблемой по сравнению с простотой использования.: -)

(Я собираюсь использовать их из С# и/или IronPython.)

Ответы

Ответ 1

Если вы счастливы читать все в памяти, используйте XDocument. Это сделает вашу жизнь намного легче. LINQ to XML - прекрасный API.

Используйте XmlReader (например, XmlTextReader), если вам нужно обрабатывать огромные XML файлы потоковым способом. Это гораздо более болезненный API, но он позволяет передавать потоки (т.е. Обрабатывать только данные по мере необходимости, поэтому вы можете пройти через огромный документ и иметь только небольшую сумму в памяти за раз).

Однако существует гибридный подход - если у вас есть огромный документ, состоящий из небольших элементов, вы можете создать XElement из XmlReader, расположенного в начале элемента, обработать элемент, используя LINQ to XML, затем переместите XmlReader на следующий элемент и начните снова.

Ответ 2

XmlTextReader является устаревшим, не используйте его.

Из дневников msdn от XmlTeam

Эффективный Xml Часть 1: выберите правильный API

Избегайте использования XmlTextReader. Он содержит довольно много ошибок, которые не могут быть исправлены без нарушения существующих приложений, уже использующих его.

Мир перешел, не так ли? Xml API, вы должны избегать использования.

Устаревшие API-интерфейсы просты, так как компилятор помогает идентифицировать их, но есть еще два API, которых следует избегать, а именно XmlTextReader и XmlTextWriter. Мы обнаружили ряд ошибок в этих классах, которые мы не могли исправить, не нарушая существующие приложения. Легким путем было бы отказаться от этих классов и попросить людей вместо этого использовать заменяющие API. К сожалению, эти два класса не могут быть помечены как устаревшие, поскольку они являются частью стандарта ECMA-335 (Common Language Infrastructure) (http://www.ecma-international.org/publications/standards/Ecma-335.htm) - companion CLILibrary.xml, который является частью раздела IV).

Хорошей новостью является то, что даже если эти классы не устарели, в .NET Framework уже есть заменяющие API, и переход к ним относительно прост. Сначала необходимо найти места, где используются XmlTextReader или XmlTextWriter (к сожалению, это ручной шаг). Теперь все вхождения XmlTextReader следует заменить на XmlReader, и все вхождения XmlTextWriter следует заменить на XmlWriter (обратите внимание, что XmlTextReader происходит от XmlReader и XmlTextWriter происходит от XmlWriter поэтому приложение уже может использовать их, например, как формальные параметры). Последний шаг - изменить способ создания объектов XmlReader/XmlWriter - вместо создания непосредственно читателя/писателя необходим статический метод factory .Create(), присутствующий как на XmlReader, так и на XmlWriter API.
Кроме того, intellisense в Visual Studio не перечисляет XmlTextReader в пространстве имен System.Xml. Класс определяется как:
```
[EditorBrowsable(EditorBrowsableState.Never)]
public class XmlTextReader : XmlReader, IXmlLineInfo, IXmlNamespaceResolver
```

Методы XmlReader.Create factory возвращают другие внутренние реализации абстрактного класса XmlReader в зависимости от переданных параметров.

Для прямого потокового API (т.е. не загружающего всю вещь в память) используйте XmlReader с помощью метода XmlReader.Create.

Чтобы упростить работу с API, перейдите в XDocument, а также LINQ To XML. Найдите XDocument vs XmlDocument здесь и здесь.