XDocument или XmlDocument

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

9.10.2009 06:19:07
Я удивляюсь, почему ребята из документации в Microsoft не поместили ни одной заметки или замечания в MSDN, чтобы уточнить их различия или когда что использовать.
Kamran Bigdely 21.05.2015 17:43:21
Некоторая информация о msdn : msdn.microsoft.com/en-us/library/… . И вопрос производительности: stackoverflow.com/questions/4383919/… . Лично мне было проще работать с LINQ to XML.
nawfal 19.08.2015 10:09:05
7 ОТВЕТОВ
РЕШЕНИЕ

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

498
9.10.2009 06:43:43
Не могли бы вы сказать мне, почему они разные? Я имею в виду, что да, XDocument выглядит довольно аккуратно, но что касается разницы в уровне DOM, разве они не xml, есть ли какая-нибудь схема, которая показывает и Microsoft X-DOM, и W3C-совместимый DOM? Спасибо.
Tarik 9.10.2009 06:36:23
Что вы подразумеваете под «схемой» и что вы подразумеваете под «шоу»? Да, они оба имеют дело со стандартным XML, но LINQ to XML - просто более приятный API для большинства вещей. Многие технологии, лежащие в основе LINQ to XML, просто не были доступны до .NET 3.5.
Jon Skeet 9.10.2009 06:39:56
Я имею в виду, отличаются ли их объектные модели документов?
Tarik 9.10.2009 06:42:33
Ну, они оба API для самого XML, так что в этом смысле они не отличаются, нет. Я подозреваю, что у обоих есть некоторые ограничения (и есть LINQ to XML, о котором я знаю, но не могу вспомнить до предела), но в большинстве случаев вы можете просто рассматривать их как одну и ту же модель с немного разными представлениями.
Jon Skeet 9.10.2009 07:09:01
@SensorSmith: Это не распространяется на все другие бонусы, такие как автоматическое выравнивание последовательностей, обработка DateTime и т. Д. Вы также можете добавить методы расширений для всего этого, но зачем изобретать LINQ to XML, если вы можете просто использовать его вместо этого?
Jon Skeet 28.10.2015 22:43:59

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

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

24
14.06.2016 07:16:56

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

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

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

36
14.06.2016 07:17:37
Я думаю, что вы имели в виду "и может быть проще работать с прямым VB.net". Потому что VB поддерживает прямое создание элементов, где C # все еще требует кода.
Brain2000 27.04.2017 15:46:30

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

14
28.10.2013 22:08:41

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

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

-8
28.04.2012 03:52:25
Я думаю, что в следующий раз вам следует подкрепить свой комментарий цифрами, так как я считаю, что вы можете ошибаться См. Blogs.msdn.com/b/codejunkie/archive/2008/10/08/…
mike 18.06.2012 06:58:46

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

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

57
16.01.2015 03:07:10
И я удивлен, что никто не заметил, что ваше утверждение обратно верно. XmlDocument предоставляет информацию о строке, а XDocument - нет.
VVS 29.12.2017 11:46:47
@VVS: вы на мгновение беспокоили меня, что я сделал ужасную опечатку, но после двойной проверки я подтверждаю, что XDocumentона предоставляет информацию о линии. См XDocument.Load с в LoadOptions.SetLineInfoкачестве второго аргумента. Если вы знаете способ получить информацию о линии, XmlDocumentмне любопытно; назад, когда я написал этот ответ, я не смог найти ни одного. Этот другой ответ, кажется, подтверждает: stackoverflow.com/a/33622102/253883
Julien Guertault 31.12.2017 19:18:25
«И вам лучше знать об этом, прежде чем вы начнете успешно использовать XmlDocument, чтобы потом обнаружить, что вам нужно все это изменить». Угадай, что я только что сделал :)
Paul 28.06.2019 09:39:48

Как уже упоминалось, несомненно, 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)");
23
19.08.2015 11:12:21