XDocument o XmlDocument

Ahora estoy aprendiendo, XmlDocumentpero me acabo de encontrar XDocumenty cuando trato de buscar la diferencia o los beneficios de ellos no puedo encontrar algo útil, ¿podría decirme por qué usaría uno sobre otro?

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

Sin embargo, si tiene la opción, le recomendaría usar XDocumenttambién aka LINQ to XML. Es mucho más simple 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 to XML, a diferencia de cualquier otra API XML que haya 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 construir elementos con secuencias de subelementos con mucha facilidad:

// 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 mencionó Brannon, estas son API en memoria en lugar de las de transmisión (aunque XStreamingElementadmite salida diferida). XmlReadery XmlWriterson 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 to XML colocando un XmlReaderal comienzo de un elemento, leyendo uno XElementy procesándolo, luego pasando al siguiente elemento, etc. Hay varias publicaciones de blog sobre esta técnica, Aquí hay uno que encontré con una búsqueda rápida .

Me sorprende que ninguna de las respuestas hasta ahora mencione el hecho de que XmlDocumentno proporciona información de línea , mientras que XDocumentsí (a través de la IXmlLineInfointerfaz).

Esta puede ser una característica crítica en algunos casos (por ejemplo, si desea informar errores en un XML, o realizar un seguimiento de dónde se definen los elementos en general) y es mejor que esté al tanto de esto antes de comenzar a implementarlo XmlDocument, para más adelante descubre que tienes que cambiarlo todo.

XmlDocumentes ideal para desarrolladores que están familiarizados con el modelo de objetos DOM XML. 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 XPathselección de nodos.

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

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

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

Una cosa que vale la pena mencionar xsly xpathque es difícil notar es que aún es posible ejecutar xpath 1.0expresiones arbitrarias en Linq 2 Xml XNodesal incluir:

using System.Xml.XPath;

y luego podemos navegar y proyectar datos usando xpathestos métodos de extensión:

• XPathSelectElement - Elemento único
• XPathSelectElements - Conjunto de nodos
• XPathEvaluate - Escalares 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)");

XDocumentes de la API de LINQ to XML, y XmlDocumentes la API de estilo DOM estándar para XML. Si conoce DOM bien y no quiere aprender LINQ to XML, vaya con XmlDocument. Si eres nuevo en ambos, mira esta página que compara los dos, y elige cuál te gusta más.

Acabo de comenzar 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.

Además, tenga en cuenta que XDocumentes compatible con Xbox 360 y Windows Phone OS 7.0. Si los orienta, desarrolle XDocumento migre desde XmlDocument.

Creo que eso XDocumenthace muchas más llamadas de creación de objetos. Sospecho que cuando manejas muchos documentos XML,XMLDocument será más rápido.

Un lugar donde esto sucede es en la gestión de los datos escaneados. 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 XMLDocument.