XDocument ou XmlDocument

504

J'apprends maintenant, XmlDocumentmais je viens de me heurter XDocumentet lorsque j'essaie de rechercher la différence ou les avantages d'entre eux, je ne trouve pas quelque chose d'utile, pourriez-vous me dire pourquoi vous utiliseriez l'un par rapport à l'autre?

Tarik
la source
13
Je me demande pourquoi les gars de la documentation de Microsoft n'ont pas mis de note ou de remarque dans MSDN pour clarifier leurs différences ou quand utiliser quoi.
Kamran Bigdely
1
Quelques informations sur msdn: msdn.microsoft.com/en-us/library/… . Et une question de performance: stackoverflow.com/questions/4383919/… . Personnellement, j'ai trouvé plus facile de travailler avec LINQ to XML.
nawfal

Réponses:

501

Si vous utilisez .NET version 3.0 ou inférieure, vous devez utiliser XmlDocumentalias l'API DOM classique. De même, vous constaterez qu'il existe d'autres API qui s'y attendront.

Si vous avez le choix, cependant, je recommanderais vivement d'utiliser XDocumentaka LINQ to XML. Il est beaucoup plus simple de créer des documents et de les traiter. Par exemple, c'est la différence entre:

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

Les espaces de noms sont assez faciles à utiliser dans LINQ to XML, contrairement à toute autre API XML que j'ai jamais vue:

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

LINQ to XML fonctionne également très bien avec LINQ - son modèle de construction vous permet de créer des éléments avec des séquences de sous-éléments très facilement:

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

C'est beaucoup plus déclaratif, ce qui correspond au style général LINQ.

Maintenant, comme Brannon l'a mentionné, il s'agit d'API en mémoire plutôt que de streaming (bien que XStreamingElementprenant en charge la sortie paresseuse). XmlReaderet XmlWritersont les moyens normaux de streaming XML dans .NET, mais vous pouvez mélanger toutes les API dans une certaine mesure. Par exemple, vous pouvez diffuser un document volumineux mais utiliser LINQ to XML en positionnant un XmlReaderau début d'un élément, en le lisant XElementet en le traitant, puis en passant à l'élément suivant, etc. Il existe divers articles de blog sur cette technique, voici celui que j'ai trouvé avec une recherche rapide .

Jon Skeet
la source
Pourriez-vous me dire pourquoi ils sont différents? Je veux dire, oui, XDocument a l'air plutôt bien, mais en ce qui concerne la différence de niveau DOM, ne sont-ils pas tous les deux xml, y a-t-il un schéma qui montre à la fois Microsoft X-DOM et DOM conforme W3C? Merci.
Tarik
3
Qu'entendez-vous par "schéma" et qu'entendez-vous par "spectacles"? Oui, ils traitent tous les deux du XML standard, mais LINQ to XML est juste une API plus agréable pour la plupart des choses. Une grande partie de la technologie derrière LINQ to XML n'était tout simplement pas disponible avant .NET 3.5.
Jon Skeet
Je veux dire si leurs modèles d'objet de document sont différents?
Tarik
6
Eh bien, ce sont deux API pour XML lui-même, donc en ce sens, elles ne sont pas différentes, non. Je soupçonne que les deux ont des limites (et il y en a une LINQ to XML que je connais mais dont je ne me souviens pas du haut de ma tête) mais dans la plupart des cas, vous pouvez simplement les traiter comme étant le même modèle avec des représentations légèrement différentes.
Jon Skeet
1
@SensorSmith: Cela ne couvre pas tous les autres bonus, comme l'aplatissement automatique des séquences, la gestion de DateTime, etc. Vous pouvez également ajouter des méthodes d'extensions pour tout cela, mais pourquoi réinventer LINQ to XML alors que vous pouvez simplement l'utiliser à la place?
Jon Skeet
57

Je suis surpris qu'aucune des réponses à ce jour ne mentionne le fait qu'il XmlDocumentne fournit aucune information de ligne , XDocumentcontrairement à (via l' IXmlLineInfointerface).

Cela peut être une fonctionnalité critique dans certains cas (par exemple si vous souhaitez signaler des erreurs dans un XML, ou garder une trace de l'endroit où les éléments sont définis en général) et vous feriez mieux de le savoir avant de commencer à implémenter avec plaisir XmlDocument, à plus tard découvrez que vous devez tout changer.

Julien Guertault
la source
1
Et je suis surpris que personne n'ait remarqué que votre déclaration est inversement vraie. XmlDocument fournit les informations de ligne alors que XDocument ne le fait pas.
VVS
4
@VVS: vous m'inquiétez un instant d'avoir fait une terrible faute de frappe, mais après avoir vérifié deux fois, je confirme que XDocumentcela fournit des informations sur la ligne. Voir XDocument.Load avec LoadOptions.SetLineInfocomme deuxième argument. Si vous connaissez un moyen d'obtenir des informations sur la ligne, XmlDocumentje suis curieux; quand j'ai écrit cette réponse, je n'en ai pas trouvé. Cette autre réponse semble confirmer: stackoverflow.com/a/33622102/253883
Julien Guertault
1
"et vous feriez mieux de le savoir avant de commencer à implémenter XmlDocument, pour découvrir plus tard que vous devez tout changer." Devinez ce que je viens de faire :)
Paul
36

XmlDocumentest idéal pour les développeurs qui connaissent le modèle d'objet DOM XML. Il existe depuis un certain temps et correspond plus ou moins à une norme W3C. Il prend en charge la navigation manuelle ainsi que la XPathsélection des nœuds.

XDocumentalimente la fonctionnalité LINQ to XML dans .NET 3.5. Il fait un usage intensif IEnumerable<>et peut être plus facile à utiliser en C # droit.

Les deux modèles de document nécessitent que vous chargiez le document entier en mémoire (contrairement XmlReaderpar exemple).

Brannon
la source
3
Je pense que vous vouliez dire "et il peut être plus facile de travailler avec directement VB.net". Parce que VB prend en charge la création directe d'éléments où C # nécessite toujours du code.
Brain2000
24

Comme mentionné ailleurs, sans aucun doute, Linq to Xml fait de la création et de la modification de documents xml un jeu d'enfant par rapport à XmlDocument, et la XNamespace ns + "elementName"syntaxe permet une lecture agréable lorsqu'il s'agit d'espaces de noms.

Une chose à noter xslet xpathà noter est qu'il est toujours possible d'exécuter des xpath 1.0expressions arbitraires sur Linq 2 Xml XNodesen incluant:

using System.Xml.XPath;

puis nous pouvons naviguer et projeter des données à l'aide de xpathces méthodes d'extension:

Par exemple, étant donné le document 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>

Nous pouvons évaluer:

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)");
StuartLC
la source
24

XDocumentprovient de l'API LINQ to XML et XmlDocumentest l'API de style DOM standard pour XML. Si vous connaissez bien DOM et que vous ne voulez pas apprendre LINQ to XML, allez-y XmlDocument. Si vous êtes nouveau dans les deux, consultez cette page qui compare les deux, et choisissez celle que vous préférez.

Je viens de commencer à utiliser LINQ to XML et j'adore la façon dont vous créez un document XML en utilisant la construction fonctionnelle. C'est vraiment sympa. DOM est maladroit en comparaison.

Daniel Chambers
la source
14

Notez également que cette fonctionnalité XDocumentest prise en charge sur Xbox 360 et Windows Phone OS 7.0. Si vous les ciblez, développez pour XDocumentou migrez à partir de XmlDocument.

w0land
la source
-8

Je crois que cela XDocumentfait beaucoup plus d'appels à la création d'objets. Je soupçonne que lorsque vous manipulez beaucoup de documents XML, ce XMLDocumentsera plus rapide.

Cela se produit notamment dans la gestion des données de numérisation. De nombreux outils d'analyse produisent leurs données en XML (pour des raisons évidentes). Si vous devez traiter beaucoup de ces fichiers d'analyse, je pense que vous aurez de meilleures performances avec XMLDocument.

Brian
la source
11
Je pense que vous devriez étayer votre commentaire avec des chiffres la prochaine fois, car je pense que vous avez peut-être tort. Voir blogs.msdn.com/b/codejunkie/archive/2008/10/08/…
mike