XDocument ou XmlDocument

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?

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 .

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.

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

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:

• XPathSelectElement - Élément unique
• XPathSelectElements - Ensemble de nœuds
• XPathEvaluate - Scalars et autres

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

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.

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.

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.