C# XmlTextReader与XDocument

我可以在.NET中解析XML。现在我至少可以在

XmlTextReader

和

XDocument

之间进行选择。这两个（或框架中包含的任何其他XML解析器）之间是否有任何比较

也许这可以帮助我做出决定，而不必深入尝试两种方法

XML文件预计会非常小，与易用性相比，速度和内存使用是一个小问题。：-）

（我将从C#和/或IronPython中使用它们。）

---

谢谢

如果您乐于将所有内容读入内存，请使用

XDocument

。这会让你的生活更轻松。LINQtoXML是一个可爱的API

基本上，如果您需要以流式方式处理庞大的XML文件，请使用

XmlReader

（例如

XmlTextReader

）。这是一个痛苦得多的API，但它允许流式传输（即，只处理您需要的数据，因此您可以浏览一个巨大的文档，一次只能在内存中保留少量数据）

---

但是，有一种混合方法-如果您有一个由小元素组成的大型文档，您可以从位于元素开头的

XmlReader

创建

XElement

，使用LINQ to XML处理元素，然后将

XmlReader

移动到下一个元素上，然后重新开始。

XmlTextReader

有点不推荐使用，不要使用它

来自XmlTeam的msdn博客

避免使用

XmlTextReader

。它包含相当多的bug，如果不破坏已经在使用它的现有应用程序，这些bug是无法修复的

过时的API很容易，因为编译器有助于识别它们，但还有两种API应该避免使用，即

XmlTextReader

和

XmlTextWriter

。我们在这些类中发现了一些bug，如果不破坏现有的应用程序，我们无法修复这些bug。简单的方法是不推荐这些类，并要求人们使用替代API。不幸的是，这两个类不能被标记为过时，因为它们是ECMA-335（公共语言基础设施）标准（）的一部分，ECMA-335标准（）是附带的CLILibrary.xml文件，它是分区IV的一部分

好消息是，尽管这些类没有被弃用，但在.NET Framework中已经有了这些类的替换API，并且迁移到它们相对容易。首先，必须找到使用

XmlTextReader

或

XmlTextWriter

的位置（不幸的是，这是一个手动步骤）。现在，所有出现的

XmlTextReader

应替换为

XmlReader

，所有出现的

XmlTextWriter

应替换为

XmlWriter

（请注意，

XmlTextReader

源于

XmlReader

，

XmlTextWriter

源于

XmlWriter

，因此应用程序已经可以使用这些参数，例如作为形式参数）。最后一步是更改实例化

XmlReader

/

XmlWriter

对象的方式–有必要使用

XmlReader

和

XmlWriter

API上的静态工厂方法

.Create（）

此外，Visual Studio中的intellisense未在System.Xml命名空间下列出

XmlTextReader

。该类定义为：

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

根据传递的设置，

XmlReader.Create

工厂方法返回抽象类

XmlReader

的其他内部实现

---

对于仅向前的流式API（即不将整个内容加载到内存中的API），请通过

XmlReader.Create

方法使用XmlReader

---

要使用更简单的API，请选择XDocumentaka LINQ to XML。查找

XDocument

vs

XmlDocument

和。

完整地说，您也可以使用XmlDocument。但与XDocument相比没有多大优势。