XDocument o XmlDocument


504

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?


13
Mi chiedo perché i ragazzi della documentazione in Microsoft non abbiano messo alcuna nota o osservazione in MSDN per chiarire le loro differenze o quando usare cosa.
Kamran Bigdely,

1
Alcune informazioni su msdn: msdn.microsoft.com/en-us/library/… . E una domanda sulle prestazioni: stackoverflow.com/questions/4383919/… . Personalmente ho trovato più facile lavorare con LINQ to XML.
nawfal,

Risposte:


501

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 .


Potresti dirmi perché sono diversi? Voglio dire, sì, XDocument sembra piuttosto pulito, ma per quanto riguarda la differenza a livello di DOM, non sono entrambi xml, esiste uno schema che mostra sia DOM X-DOM che DOM compatibile W3C? Grazie.
Tarik,

3
Cosa intendi con "schema" e cosa intendi con "spettacoli"? Sì, entrambi trattano XML standard, ma LINQ to XML è solo un'API più bella per la maggior parte delle cose. Molta della tecnologia dietro LINQ to XML semplicemente non era disponibile prima di .NET 3.5.
Jon Skeet,

Voglio dire se i loro modelli di oggetti documento sono diversi?
Tarik,

6
Beh, sono entrambe API per XML stesso, quindi in questo senso non sono diverse, no. Sospetto che entrambi abbiano alcune limitazioni (e c'è un LINQ to XML che conosco ma che non ricordo nella parte superiore della mia testa) ma nella maggior parte dei casi puoi semplicemente trattarli come lo stesso modello con rappresentazioni leggermente diverse.
Jon Skeet,

1
@SensorSmith: Questo non copre tutti gli altri bonus, come l'appiattimento automatico delle sequenze, la gestione di DateTime ecc. Potresti aggiungere anche metodi di estensione per tutto ciò, ma perché reinventare LINQ to XML quando puoi semplicemente usarlo?
Jon Skeet,

57

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.


1
E sono sorpreso che nessuno abbia notato che la tua affermazione è inversamente vera. XmlDocument fornisce le informazioni sulla linea mentre XDocument no.
VVS

4
@VVS: mi hai fatto preoccupare per un momento che avevo fatto un errore terribile, ma dopo un doppio controllo, confermo che XDocumentfornisce informazioni sulla linea. Vedi XDocument.Load con LoadOptions.SetLineInfocome secondo argomento. Se conosci un modo per ottenere informazioni sulla linea con XmlDocumentsono curioso; quando ho scritto questa risposta non sono riuscito a trovarne. Questa altra risposta sembra confermare: stackoverflow.com/a/33622102/253883
Julien Guertault

1
"e farai meglio a saperlo prima di iniziare felicemente a implementare usando XmlDocument, per scoprire in seguito che devi cambiare tutto." Indovina cosa ho appena fatto :)
Paul,

36

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


3
Penso che volevi dire "e può essere più facile lavorare con VB.net". Perché VB supporta la creazione diretta di elementi in cui C # richiede ancora codice.
Brain2000

24

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:

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

24

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.


14

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.


-8

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.


11
Penso che dovresti sostenere il tuo commento con cifre la prossima volta, poiché credo che potresti sbagliare. Vedi blogs.msdn.com/b/codejunkie/archive/2008/10/08/…
mike,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.