J'apprends maintenant, XmlDocument
mais je viens de me heurter XDocument
et 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?
c#
xml
xmldocument
linq-to-xml
Tarik
la source
la source
Réponses:
Si vous utilisez .NET version 3.0 ou inférieure, vous devez utiliser
XmlDocument
alias 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
XDocument
aka 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:et
Les espaces de noms sont assez faciles à utiliser dans LINQ to XML, contrairement à toute autre API XML que j'ai jamais vue:
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:
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
XStreamingElement
prenant en charge la sortie paresseuse).XmlReader
etXmlWriter
sont 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 unXmlReader
au début d'un élément, en le lisantXElement
et 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 .la source
Je suis surpris qu'aucune des réponses à ce jour ne mentionne le fait qu'il
XmlDocument
ne fournit aucune information de ligne ,XDocument
contrairement à (via l'IXmlLineInfo
interface).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.la source
XDocument
cela fournit des informations sur la ligne. Voir XDocument.Load avecLoadOptions.SetLineInfo
comme deuxième argument. Si vous connaissez un moyen d'obtenir des informations sur la ligne,XmlDocument
je 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/253883XmlDocument
est 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 laXPath
sélection des nœuds.XDocument
alimente la fonctionnalité LINQ to XML dans .NET 3.5. Il fait un usage intensifIEnumerable<>
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
XmlReader
par exemple).la source
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 laXNamespace ns + "elementName"
syntaxe permet une lecture agréable lorsqu'il s'agit d'espaces de noms.Une chose à noter
xsl
etxpath
à noter est qu'il est toujours possible d'exécuter desxpath 1.0
expressions arbitraires sur Linq 2 XmlXNodes
en incluant:puis nous pouvons naviguer et projeter des données à l'aide de
xpath
ces méthodes d'extension:Par exemple, étant donné le document Xml:
Nous pouvons évaluer:
la source
XDocument
provient de l'API LINQ to XML etXmlDocument
est l'API de style DOM standard pour XML. Si vous connaissez bien DOM et que vous ne voulez pas apprendre LINQ to XML, allez-yXmlDocument
. 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.
la source
Notez également que cette fonctionnalité
XDocument
est prise en charge sur Xbox 360 et Windows Phone OS 7.0. Si vous les ciblez, développez pourXDocument
ou migrez à partir deXmlDocument
.la source
Je crois que cela
XDocument
fait beaucoup plus d'appels à la création d'objets. Je soupçonne que lorsque vous manipulez beaucoup de documents XML, ceXMLDocument
sera 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
.la source