XDocument o XmlDocument

Question

Ahora estoy aprendiendo XmlDocument pero acabo de encontrar XDocument y cuando trato de buscar la diferencia o los beneficios de ellos no puedo encontrar algo útil, ¿podría decirme por qué usaría uno más? otro?

Answer 1

Si está utilizando .NET versión 3.0 o inferior, tiene para usar XmlDocument también conocido como el DOM API clásico. Del mismo modo, encontrarás que hay otras API que esperan esto.

Si tiene la opción, sin embargo, recomendaría completamente usar XDocument aka LINQ to XML. Es mucho más simple para crear documentos y procesarlos. Por ejemplo, es la diferencia 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); 

y

XDocument doc = new XDocument(
    new XElement("root", 
       new XAttribute("name", "value"), 
       new XElement("child", "text node"))); 

Los espacios de nombres son bastante fáciles de trabajar en LINQ para XML, a diferencia de cualquier otro API XML cada vez que he visto:

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

LINQ to XML también funciona muy bien con LINQ - su modelo de construcción le permite crear elementos con secuencias de subelementos muy fácilmente:

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

Todo es mucho más declarativo, lo que encaja con el estilo general de LINQ.

Ahora, como lo mencionó Brannon, se trata de API en memoria en lugar de transmisión (aunque XStreamingElement admite salida diferida). XmlReader y XmlWriter son las formas normales de transmisión de XML en .NET, pero puede mezclar todas las API hasta cierto punto. Por ejemplo, puede transmitir un documento grande pero usar LINQ a XML colocando un XmlReader al comienzo de un elemento, leyendo un XElement y procesándolo, luego pasando al siguiente elemento, etc. Hay varias publicaciones en el blog sobre este tema. técnica, here's one I found with a quick search.

Answer 2

XDocument es de la API LINQ a XML, y XmlDocument es la API estándar de DOM para XML. Si conoce DOM correctamente y no quiere aprender LINQ a XML, vaya con XmlDocument. Si eres nuevo en ambos, echa un vistazo a this page que compara los dos y elige cuál te gusta más.

Acabo de empezar a usar LINQ to XML, y me encanta la forma de crear un documento XML con una construcción funcional. Es realmente bueno. DOM es torpe en comparación.

Answer 3

XmlDocument es ideal para desarrolladores que están familiarizados con el modelo de objetos XML DOM. Ha existido por un tiempo, y más o menos corresponde a un estándar W3C. Admite la navegación manual y la selección de nodos XPath.

XDocument potencia la característica LINQ to XML en .NET 3.5. Hace un uso intensivo de IEnumerable<> y puede ser más fácil trabajar con C# directo.

Ambos modelos de documentos requieren que cargue todo el documento en la memoria (a diferencia de XmlReader por ejemplo).

Answer 4

Además, tenga en cuenta que XDocument es compatible con Xbox 360 y Windows Phone OS 7.0. Si los selecciona, desarrolle para XDocument o migre desde XmlDocument.

Answer 5

Creo que XDocument hace muchas más llamadas a la creación de objetos. Sospecho que para cuando maneje una gran cantidad de documentos XML, XMLDocument será más rápido.

Un lugar en el que esto sucede es en la gestión de datos escaneados. Muchas herramientas de escaneo envían sus datos en XML (por razones obvias). Si tiene que procesar muchos de estos archivos de escaneo, creo que tendrá un mejor rendimiento con XMLDocument.

Answer 6

me sorprende que ninguna de las respuestas hasta el momento menciona el hecho de que XmlDocument no proporciona ninguna información de la línea, mientras XDocument hace (a través de la interfaz IXmlLineInfo).

Esto puede ser una característica crítica en algunos casos (por ejemplo, si desea informar errores en un XML, o hacer un seguimiento de dónde se definen los elementos en general) y es mejor que lo tenga en cuenta antes de comenzar a implementar usando XmlDocument, para descubrir más tarde, debe cambiarlo todo.

Answer 7

Además del comentario anterior de W0lands, lo mismo se aplica al construir proyectos Unity3D para Windows 8. También necesitará usar XDocument en este escenario.

Answer 8

Como se mencionó en otra parte, sin duda, Linq a Xml hace que la creación y alteración de documentos xml sea muy fácil en comparación con XmlDocument, y la sintaxis XNamespace ns + "elementName" hace que la lectura sea placentera al tratar con espacios de nombres.

Una cosa vale la pena mencionar a xsl y xpath recalcitrantes a tener en cuenta es que es posible todavía ejecutar arbitrarias xpath 1.0 expresiones en LINQ 2 XML XNodes incluyendo:

using System.Xml.XPath; 

y entonces podremos navegar y datos del proyecto usando xpath a través de estos métodos de extensión:

• XPathSelectElement - Single Element
• XPathSelectElements - Conjunto de nodos
• XPathEvaluate - escalares y otros

Por ejemplo, teniendo en cuenta el 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> 

podemos evaluar:

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