XmlTextReader与XDocument

我能够在.NET中解析XML。 现在我可以选择至少XmlTextReader和XDocument 。 这两个（或框架中包含的任何其他XML解析器）之间是否有任何比较？

也许这可以帮助我做出决定而不必深入尝试它们。

与易于使用相比，XML文件预计相当小，速度和内存使用是一个小问题。 🙂

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

谢谢！

Answer 1

如果您乐意将所有内容都读入内存，请使用XDocument 。 它会让你的生活更轻松。 LINQ to XML是一个可爱的 API。

如果需要以流式方式处理大型 XML文件，请使用XmlReader （例如XmlTextReader ）。 这是一个更痛苦的API，但它允许流式传输（即只需要处理数据，因此您可以浏览一个巨大的文档，一次只有少量的内存）。

然而，有一种混合方法 – 如果你有一个由小元素组成的巨大文档，你可以从位于元素开头的XmlReader创建一个XElement ，使用LINQ to XML处理元素，然后将XmlReader移动到下一个元素然后重新开始。

Answer 2

XmlTextReader是一种不推荐使用的，不要使用它。

1. 来自XmlTeam的msdn博客

   有效的Xml第1部分：选择正确的API

   避免使用XmlTextReader 。 它包含了一些在不破坏已经使用它的现有应用程序的情况下无法修复的错误。

   世界已经转移，对吗？ 您应该避免使用的Xml API。

   过时的API很容易，因为编译器有助于识别它们，但是还有两个应该避免使用的API – 即XmlTextReader和XmlTextWriter 。 我们在这些类中发现了许多错误，我们无法在不破坏现有应用程序的情况下修复这些错误。 简单的方法是弃用这些类并要求人们使用替换API。 不幸的是，这两个类不能被标记为过时，因为它们是ECMA-335（公共语言基础结构）标准（ http://www.ecma-international.org/publications/standards/Ecma-335.htm ）的一部分 – 伴侣CLILibrary .xml文件，它是分区IV的一部分）。

   好消息是，尽管这些类没有被弃用，但在.NET Framework中已有替换API，并且转移到它们相对容易。 首先，有必要找到使用XmlTextReader或XmlTextWriter的地方（不幸的是，这是一个手动步骤）。 现在所有出现的XmlTextReader都应该用XmlReader替换，并且所有出现的XmlTextWriter都应该用XmlWriter替换（注意XmlTextReader派生自XmlReader ， XmlTextWriter派生自XmlWriter因此应用程序已经可以使用这些作为forms参数）。 最后一步是更改XmlReader / XmlWriter对象的实例化方式 – 而不是直接创建读取器/ .Create()器，必须在XmlReader和XmlWriter API上都存在静态工厂方法.Create() 。

2. 此外，Visual Studio中的intellisense不会在System.Xml命名空间下列出XmlTextReader 。 该类定义为：

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

XmlReader.Create工厂方法根据传递的设置返回抽象类XmlReader其他内部实现。

---

对于仅转发的流API（即不将整个内容加载到内存中），请通过XmlReader.Create方法使用XmlReader 。

要获得更简单的API，请转到XDocument，即LINQ To XML。 在这里和这里找到XDocument vs XmlDocument 。