XDocument или XmlDocument - PullRequest
Новая
       48

XDocument или XmlDocument

479 голосов
/ 09 октября 2009

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

Ответы [ 7 ]

475 голосов
/ 09 октября 2009

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

Однако, если у вас есть выбор, я бы настоятельно рекомендовал использовать XDocument aka 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, в отличие от любого другого API XML, который я когда-либо видел: 

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 и обработав его, затем перейдя к следующему элементу и т. Д. в блогах об этой технике вот что я нашел с помощью быстрого поиска .

54 голосов
/ 29 августа 2012

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

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

34 голосов
/ 09 октября 2009

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

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

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

23 голосов
/ 09 октября 2009

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

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

22 голосов
/ 20 декабря 2014

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

Одна вещь, о которой стоит упомянуть, для xsl и xpath уместно отметить, что можно по-прежнему выполнять произвольные 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)");
14 голосов
/ 27 сентября 2010

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

0 голосов
/ 28 апреля 2012

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

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

...