我能够在.NET中解析XML。现在我可以选择至少XmlTextReader和XDocument。这两者（或框架中包含的任何其他XML解析器）之间是否有任何比较？
也许这可以帮助我做出决定而不必深入尝试它们。
与使用的简便性相比，XML文件预计相当小，速度和内存使用是一个小问题。 ： - ）
（我将从C＃和/或IronPython中使用它们。）
谢谢！
答案 0 :(得分：36)
如果您乐意将所有内容都读入内存，请使用XDocument。它会让你的生活更轻松。 LINQ to XML是一个可爱的 API。
如果您需要以流式方式处理巨大的 XML文件，请使用XmlReader（例如XmlTextReader）。这是一个更痛苦的API，但它允许流式传输（即只根据需要处理数据，因此您可以浏览一个巨大的文档，一次只有少量的内存）。
然而，有一种混合方法 - 如果你有一个由小元素组成的巨大文档，你可以从位于元素开头的XElement创建一个XmlReader，处理元素使用LINQ to XML，然后将XmlReader移到下一个元素上并重新开始。
答案 1 :(得分：10)
XmlTextReader有点弃用，请勿使用它。
来自msdn blogs by XmlTeam
Effective Xml Part 1: Choose the right API
避免使用
XmlTextReader。它包含了一些在不破坏已经使用它的现有应用程序的情况下无法修复的错误。
The world has moved on, have you? Xml APIs you should avoid using.
过时的API很容易，因为编译器有助于识别它们，但还有两个应该避免使用的API - 即
XmlTextReader和XmlTextWriter。我们在这些类中发现了许多错误，我们无法在不破坏现有应用程序的情况下修复这些错误。简单的方法是弃用这些类，并要求人们使用替换API。不幸的是，这两个类不能被标记为过时，因为它们是ECMA-335（公共语言基础结构）标准（http://www.ecma-international.org/publications/standards/Ecma-335.htm）的一部分 - 伴随CLILibrary.xml文件，它是分区IV的一部分。）好消息是，尽管这些类没有被弃用，但.NET Framework中已经有替换这些类，并且转移它们相对容易。首先，有必要找到使用
XmlTextReader或XmlTextWriter的地方（不幸的是，这是一个手动步骤）。现在XmlTextReader的所有出现都应该替换为XmlReader，XmlTextWriter的所有出现都应该替换为XmlWriter（请注意XmlTextReader来自{XmlReader1}}和XmlTextWriter派生自XmlWriter，因此应用已经可以使用这些作为正式参数）。最后一步是更改实例化XmlReader/XmlWriter对象的方式 - 而不是直接创建读取器/编写器，而.Create()上的静态工厂方法XmlReader是必需的。 1}}和XmlWriterAPI。
此外，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与XmlDocument here和here。