XDocument o XmlDocument

Ora sto imparando XmlDocumentma mi sono appena imbattuto XDocumente quando provo a cercare la differenza o i vantaggi di essi non riesco a trovare qualcosa di utile, potresti per favore dirmi perché dovresti usarne uno sopra l'altro?

Se si sta utilizzando .NET versione 3.0 o inferiore, è necessario utilizzare XmlDocumentalias il classico API DOM. Allo stesso modo troverai alcune altre API che si aspettano questo.

Se hai la scelta, tuttavia, consiglierei vivamente di usare XDocumentanche LINQ to XML. È molto più semplice creare documenti ed elaborarli. Ad esempio, è la differenza tra:

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

e

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

Gli spazi dei nomi sono abbastanza facili da lavorare in LINQ to XML, a differenza di qualsiasi altra API XML che abbia mai visto:

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

LINQ to XML funziona anche molto bene con LINQ: il suo modello di costruzione consente di creare elementi con sequenze di sottoelementi in modo molto semplice:

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

È tutto molto più dichiarativo, che si adatta allo stile generale LINQ.

Ora, come menzionato da Brannon, si tratta di API in memoria piuttosto che di streaming (sebbene XStreamingElementsupporti l'output pigro). XmlReadere XmlWritersono i normali modi di trasmettere XML in .NET, ma è possibile mescolare tutte le API in una certa misura. Ad esempio, puoi eseguire lo streaming di un documento di grandi dimensioni ma utilizzare LINQ to XML posizionando XmlReaderall'inizio di un elemento, leggendo un XElementda esso ed elaborandolo, quindi passando all'elemento successivo ecc. Esistono vari post di blog su questa tecnica, eccone uno che ho trovato con una rapida ricerca .

Sono sorpreso che nessuna delle risposte finora menziona il fatto che XmlDocumentnon fornisce informazioni sulla linea , mentre lo XDocumentfa (attraverso l' IXmlLineInfointerfaccia).

Questa può essere una funzionalità critica in alcuni casi (ad esempio se si desidera segnalare errori in un XML o tenere traccia di dove gli elementi sono definiti in generale) ed è meglio esserne consapevoli prima di iniziare felicemente a implementare usando XmlDocument, per in seguito scopri che devi cambiare tutto.

XmlDocumentè ottimo per gli sviluppatori che hanno familiarità con il modello di oggetti DOM XML. È in circolazione da un po 'e più o meno corrisponde a uno standard W3C. Supporta anche la navigazione manualeXPath selezione dei nodi.

XDocumentalimenta la funzionalità LINQ to XML in .NET 3.5. Fa un uso pesante diIEnumerable<> e può essere più facile lavorare con C # dritto.

Entrambi i modelli di documento richiedono di caricare l'intero documento in memoria (a differenza, XmlReaderad esempio).

Come menzionato altrove, senza dubbio, Linq to Xml rende la creazione e l'alterazione di documenti xml un gioco da ragazzi in confronto XmlDocumenteXNamespace ns + "elementName" sintassi rende piacevole la lettura quando si tratta di spazi dei nomi.

Una cosa degna di nota xsle xpathdifficile da notare è che è possibile eseguire xpath 1.0espressioni arbitrarie su Linq 2 Xml XNodesincludendo:

using System.Xml.XPath;

e quindi possiamo navigare e proiettare i dati usando xpathquesti metodi di estensione:

• XPathSelectElement - Single Element
• XPathSelectElements - Set di nodi
• XPathEvaluate : scalari e altri

Ad esempio, dato il documento 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>

Siamo in grado di valutare:

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

XDocumentproviene dall'API LINQ to XML ed XmlDocumentè l'API stile DOM standard per XML. Se conosci bene DOM e non vuoi imparare LINQ to XML, vai con XmlDocument. Se sei nuovo per entrambi, dai un'occhiata a questa pagina che confronta i due e scegli quale ti piace l'aspetto migliore.

Ho appena iniziato a utilizzare LINQ to XML e adoro il modo in cui crei un documento XML usando la costruzione funzionale. È davvero carino. DOM è goffo in confronto.

Inoltre, si noti che XDocumentè supportato in Xbox 360 e Windows Phone OS 7.0. Se li scegli come target, sviluppa XDocumento migra da XmlDocument.

Credo che XDocumentfaccia molte più chiamate alla creazione di oggetti. Sospetto che per quando gestisci molti documenti XML,XMLDocument sarà più veloce.

Un punto in cui ciò accade è nella gestione dei dati di scansione. Molti strumenti di scansione producono i propri dati in XML (per ovvi motivi). Se devi elaborare molti di questi file di scansione, penso che avrai prestazioni migliori con XMLDocument.