XDocument oder XmlDocument

Question

Ich lerne jetzt XmlDocument aber ich bin gerade auf XDocument und wenn ich versuche, den Unterschied oder die Vorteile von ihnen zu suchen, kann ich nicht etwas Nützliches finden, könnten Sie mir bitte sagen, warum Sie eine über eine andere verwenden würde?

Answer 1

Wenn Sie .NET Version 3.0 oder niedriger verwenden, können Sie haben zu verwenden XmlDocument auch bekannt als die klassische DOM-API. Ebenso werden Sie feststellen, dass es einige andere APIs gibt, die dies erwarten.

Wenn Sie die Wahl haben, würde ich Ihnen jedoch empfehlen, die XDocument auch bekannt als LINQ to XML. Es ist viel einfacher, Dokumente zu erstellen und zu bearbeiten. Das ist zum Beispiel der Unterschied zwischen:

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);

et

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

Namespaces sind in LINQ to XML ziemlich einfach zu handhaben, im Gegensatz zu allen anderen XML-APIs, die ich kenne:

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

LINQ to XML funktioniert auch sehr gut mit LINQ - sein Konstruktionsmodell ermöglicht es Ihnen, Elemente mit Sequenzen von Unterelementen sehr einfach zu erstellen:

// 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
    ));

Es ist alles viel deklarativer, was zum allgemeinen LINQ-Stil passt.

Wie Brannon bereits erwähnt hat, handelt es sich hierbei um In-Memory-APIs und nicht um Streaming-APIs (obwohl XStreamingElement unterstützt faule Ausgabe). XmlReader y XmlWriter sind die üblichen Methoden für das Streaming von XML in .NET, aber Sie können alle APIs bis zu einem gewissen Grad mischen. Sie können zum Beispiel ein großes Dokument streamen, aber LINQ to XML verwenden, indem Sie eine XmlReader am Anfang eines Elements, das Lesen einer XElement und verarbeitet es, dann geht es weiter zum nächsten Element usw. Es gibt verschiedene Blogbeiträge über diese Technik, hier ist eine, die ich bei einer schnellen Suche gefunden habe .

Answer 2

Ich bin überrascht, dass bisher in keiner der Antworten die Tatsache erwähnt wurde, dass XmlDocument liefert keine Leitungsinformationen , während XDocument tut (durch die IXmlLineInfo Schnittstelle).

Dies kann in einigen Fällen eine kritische Funktion sein (z.B. wenn Sie Fehler in einer XML-Datei melden oder nachverfolgen wollen, wo Elemente im Allgemeinen definiert sind), und Sie sollten sich dessen bewusst sein, bevor Sie mit der Implementierung von XmlDocument um später festzustellen, dass man alles ändern muss.

Answer 3

XmlDocument ist ideal für Entwickler, die mit dem XML-DOM-Objektmodell vertraut sind. Es gibt es schon eine Weile, und es entspricht mehr oder weniger einem W3C-Standard. Es unterstützt sowohl die manuelle Navigation als auch die XPath Knotenauswahl.

XDocument unterstützt die LINQ to XML-Funktion in .NET 3.5. Sie macht intensiven Gebrauch von IEnumerable<> und kann in reinem C# einfacher zu handhaben sein.

Bei beiden Dokumentenmodellen müssen Sie das gesamte Dokument in den Speicher laden (im Gegensatz zu XmlReader zum Beispiel).

Answer 4

Wie bereits an anderer Stelle erwähnt, macht Linq to Xml die Erstellung und Änderung von XML-Dokumenten zu einem Kinderspiel im Vergleich zu XmlDocument und die XNamespace ns + "elementName" Syntax sorgt für ein angenehmes Lesevergnügen beim Umgang mit Namensräumen.

Eine erwähnenswerte Sache für xsl y xpath Die Harten müssen beachten, dass es immer noch möglich ist, beliebige xpath 1.0 Ausdrücke zu Linq 2 Xml XNodes durch Einbeziehung:

using System.Xml.XPath;

und dann können wir navigieren und Daten projizieren mit xpath über diese Erweiterungsmethoden:

• XPathSelectElement - Einzelnes Element
• XPathSelectElements - Knotenpunktsatz
• XPathEvaluate - Narben und andere

Nehmen wir zum Beispiel das Xml-Dokument:

<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>

Wir können bewerten:

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)");

Answer 5

XDocument stammt aus der LINQ to XML API, und XmlDocument ist die Standard-API im DOM-Stil für XML. Wenn Sie sich mit DOM gut auskennen und LINQ to XML nicht lernen wollen, sollten Sie sich für XmlDocument . Wenn Sie beides noch nicht kennen, lesen Sie diese Seite die beide miteinander vergleicht, und entscheiden Sie sich für diejenige, die Ihnen besser gefällt.

Ich habe gerade angefangen, LINQ to XML zu verwenden, und mir gefällt die Art und Weise, wie Sie ein XML-Dokument mit funktionaler Konstruktion erstellen. Das ist wirklich schön. DOM ist im Vergleich dazu klobig.