XDocument или XmlDocument

Я сейчас учусь XmlDocument но я только что столкнулся с XDocument и когда я пытаюсь найти разницу или преимущества их, я не могу найти что-то полезное, не могли бы вы сказать мне, почему вы будете использовать один над другим ?

8 ответов


если вы используете .NET версии 3.0 или ниже, вы есть использовать XmlDocument Он же классический DOM API. Точно так же вы найдете некоторые другие API, которые будут ожидать этого.

если вы получаете выбор, однако, я бы тщательно рекомендовал использовать XDocument Он же LINQ to XML. Это много проще создавать документы и обрабатывать их. Например, это разница между:

XmlDocument doc = new XmlDocument();
XmlElement root = doc.CreateElement("root");
root.SetAttribute("name", "value");
XmlElement child = doc.CreateElement("child");
child.InnerText = "text node";
root.AppendChild(child);
doc.AppendChild(root);

и

XDocument doc = new XDocument(
    new XElement("root",
                 new XAttribute("name", "value"),
                 new XElement("child", "text node")));

пространства имен довольно легко работать с LINQ to XML, в отличие от любого другого XML API, который я когда-либо видел:

XNamespace ns = "http://somewhere.com";
XElement element = new XElement(ns + "elementName");
// etc

LINQ to XML также очень хорошо работает с LINQ-его модель построения позволяет легко создавать элементы с последовательностями подэлементов:

// Customers is a List<Customer>
XElement customersElement = new XElement("customers",
    customers.Select(c => new XElement("customer",
        new XAttribute("name", c.Name),
        new XAttribute("lastSeen", c.LastOrder)
        new XElement("address",
            new XAttribute("town", c.Town),
            new XAttribute("firstline", c.Address1),
            // etc
    ));

это все намного более декларативно, что соответствует общему стилю LINQ.

теперь, как упоминал Брэннон, это API в памяти, а не потоковые (хотя XStreamingElement поддерживает ленивый выход.) XmlReader и XmlWriter являются обычными способами потоковой передачи XML в .NET, но вы можете в некоторой степени смешивать все API. Например, вы можете передавать большой документ, но использовать LINQ to XML, располагая XmlReader в начале элемента, значение элемента XElement от него и обрабатывает его, затем перейти к следующему элементу и т. д. Есть различные сообщения в блоге об этой технике,вот один, который я нашел с быстрым поиском.


Я удивлен, что ни один из ответов до сих пор упоминает тот факт, что XmlDocument нет информации строка, а XDocument тут (через IXmlLineInfo интерфейс).

В некоторых случаях это может быть критической функцией (например, если вы хотите сообщить об ошибках в XML или отслеживать, где элементы определены в целом), и вам лучше знать об этом, прежде чем вы с радостью начнете реализовывать использование XmlDocument, чтобы позже обнаружить, вы нужно все изменить.


XmlDocument отлично подходит для разработчиков, которые знакомы с объектной моделью XML DOM. Он существует уже некоторое время и более или менее соответствует стандарту W3C. Он поддерживает ручную навигацию, а также XPath выбор узла.

XDocument включает функцию LINQ to XML в .NET 3.5. Это делает тяжелое использование IEnumerable<> и может быть проще работать с прямым C#.

обе модели документов требуют, чтобы вы загрузили весь документ в память (в отличие от XmlReader для образец.)


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

Я только начал использовать LINQ to XML, и мне нравится, как вы создаете XML-документ с помощью функциональной конструкции. Очень мило. По сравнению с ним дом неуклюж.


как упоминалось в другом месте, несомненно, Linq to Xml делает создание и изменение xml-документов ветер по сравнению с XmlDocument и XNamespace ns + "elementName" синтаксиса для более комфортного чтения при работе с пространствами имен.

одна вещь, стоит отметить для xsl и xpath die hards отметить, что можно по-прежнему выполнять произвольные xpath 1.0 выражения на Linq 2 Xml XNodes, включая:

using System.Xml.XPath;

и тогда мы можем перемещаться и проектировать данные используя xpath С помощью этих методов расширения:

например, учитывая Xml-документ:

<xml>
    <foo>
        <baz id="1">10</baz>
        <bar id="2" special="1">baa baa</bar>
        <baz id="3">20</baz>
        <bar id="4" />
        <bar id="5" />
    </foo>
    <foo id="123">Text 1<moo />Text 2
    </foo>
</xml>

мы можем оценить:

var node = xele.XPathSelectElement("/xml/foo[@id='123']");
var nodes = xele.XPathSelectElements(
"//moo/ancestor::xml/descendant::baz[@id='1']/following-sibling::bar[not(@special='1')]");
var sum = xele.XPathEvaluate("sum(//foo[not(moo)]/baz)");

кроме того, обратите внимание, что XDocument поддерживается в Xbox 360 и Windows Phone OS 7.0. Если вы нацелены на них, разработайте для XDocument или перенести от XmlDocument.


в дополнение к комментарию w0lands выше, то же самое применяется при создании проектов Unity3D для Windows 8. Вам также нужно будет использовать XDocument в этом сценарии.


Я считаю, что XDocument делает намного больше вызовов создания объектов. Я подозреваю, что, когда вы обрабатываете много XML-документов,XMLDocument будет быстрее.

одном месте это происходит в управлении сканирование данных. Много средств сканирования данных в XML (по понятным причинам). Если вам нужно обработать много этих файлов сканирования, я думаю, у вас будет лучшая производительность с XMLDocument.