c# - tutorial - XDocument o XmlDocument

xdocument c# example

Question

Ahora estoy aprendiendo XmlDocument pero acabo de encontrarme con XDocument y cuando trato de buscar la diferencia o los beneficios de ellos, no encuentro algo útil. ¿Podría decirme por qué usaría uno sobre otro?

Answer 1

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

Answer 2

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

Answer 3

Como se mencionó en otra parte, sin duda, Linq to Xml hace que la creación y alteración de documentos xml sea una brisa en comparación con XmlDocument , y la XNamespace ns + "elementName" hace que la lectura sea placentera cuando se trata de espacios de nombres.

Una cosa que vale la pena mencionar para los problemas de xsl y xpath die es que es posible ejecutar expresiones xpath 1.0 arbitrarias en XNodes Xml de Linq 2 al incluir:

using System.Xml.XPath;

y luego podemos navegar y proyectar datos usando xpath través de estos métodos de extensión:

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

Por ejemplo, dado 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)");

Answer 4

Creo que XDocument hace muchas más llamadas de creación de objetos. Sospecho que para cuando XMLDocument muchos documentos XML, XMLDocument será más rápido.

Un lugar donde esto sucede es en la gestión de datos de escaneo. Muchas herramientas de escaneo generan 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 5

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

Esta 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 esté al tanto de esto antes de comenzar a implementar el uso de XmlDocument . Más tarde descubrirás que tienes que cambiarlo todo.

Answer 6

Si está utilizando .NET versión 3.0 o inferior, tiene que usar XmlDocument también XmlDocument como la API clásica de DOM. Del mismo modo, encontrará que hay otras API que lo esperan.

Sin embargo, si tiene la opción, recomendaría usar XDocument aka LINQ to XML. Es mucho más sencillo 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 usar en LINQ to XML, a diferencia de cualquier otra API XML 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 de manera muy sencilla:

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

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

Ahora, como mencionó Brannon, estas son las API en memoria en lugar de las de transmisión por secuencias (aunque XStreamingElement admite el rendimiento lento). XmlReader y XmlWriter son las formas normales de transmitir XML en .NET, pero puedes mezclar todas las API hasta cierto punto. Por ejemplo, puede transmitir un documento grande pero usar LINQ to XML colocando un XmlReader al inicio de un elemento, leyendo un XElement de él y procesándolo, luego pasar al siguiente elemento, etc. Hay varias publicaciones de blog sobre este Técnica, aquí hay una que encontré con una búsqueda rápida .

Answer 7

XDocument es de la API de LINQ a XML, y XmlDocument es la API estándar de estilo DOM para XML. Si conoce bien DOM y no quiere aprender LINQ to XML, vaya con XmlDocument . Si eres nuevo en ambos, echa un vistazo a esta página que compara los dos y elige cuál te gusta para que se vea mejor.

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

Answer 8

XmlDocument es ideal para los 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. Es compatible con la navegación manual, así como 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).