I am now learning XmlDocument
but I've just ran into XDocument
and when I try to search the difference or benefits of them I can't find something useful, could you please tell me why you would use one over another ?
相关问题
- Sorting 3 numbers without branching [closed]
- Illegal to have multiple roots (start tag in epilo
- Graphics.DrawImage() - Throws out of memory except
- Why am I getting UnauthorizedAccessException on th
- 求获取指定qq 资料的方法
XDocument
is from the LINQ to XML API, andXmlDocument
is the standard DOM-style API for XML. If you know DOM well, and don't want to learn LINQ to XML, go withXmlDocument
. If you're new to both, check out this page that compares the two, and pick which one you like the looks of better.I've just started using LINQ to XML, and I love the way you create an XML document using functional construction. It's really nice. DOM is clunky in comparison.
As mentioned elsewhere, undoubtedly, Linq to Xml makes creation and alteration of xml documents a breeze in comparison to
XmlDocument
, and theXNamespace ns + "elementName"
syntax makes for pleasurable reading when dealing with namespaces.One thing worth mentioning for
xsl
andxpath
die hards to note is that it IS possible to still execute arbitraryxpath 1.0
expressions on Linq 2 XmlXNodes
by including:and then we can navigate and project data using
xpath
via these extension methods:For instance, given the Xml document:
We can evaluate:
in addition to W0lands comment above, the same applies when building Unity3D projects for Windows 8. You'll need to use XDocument in this scenario too.
I believe that
XDocument
makes a lot more object creation calls. I suspect that for when you're handling a lot of XML documents,XMLDocument
will be faster.One place this happens is in managing scan data. Many scan tools output their data in XML (for obvious reasons). If you have to process a lot of these scan files, I think you'll have better performance with
XMLDocument
.If you're using .NET version 3.0 or lower, you have to use
XmlDocument
aka the classic DOM API. Likewise you'll find there are some other APIs which will expect this.If you get the choice, however, I would thoroughly recommend using
XDocument
aka LINQ to XML. It's much simpler to create documents and process them. For example, it's the difference between:and
Namespaces are pretty easy to work with in LINQ to XML, unlike any other XML API I've ever seen:
LINQ to XML also works really well with LINQ - its construction model allows you to build elements with sequences of sub-elements really easily:
It's all a lot more declarative, which fits in with the general LINQ style.
Now as Brannon mentioned, these are in-memory APIs rather than streaming ones (although
XStreamingElement
supports lazy output).XmlReader
andXmlWriter
are the normal ways of streaming XML in .NET, but you can mix all the APIs to some extent. For example, you can stream a large document but use LINQ to XML by positioning anXmlReader
at the start of an element, reading anXElement
from it and processing it, then moving on to the next element etc. There are various blog posts about this technique, here's one I found with a quick search.I am surprised none of the answers so far mentions the fact that
XmlDocument
provides no line information, whileXDocument
does (through theIXmlLineInfo
interface).This can be a critical feature in some cases (for example if you want to report errors in an XML, or keep track of where elements are defined in general) and you better be aware of this before you happily start to implement using
XmlDocument
, to later discover you have to change it all.