XDocument ou XmlDocument

Agora estou aprendendo XmlDocument mas acabei de encontrar o XDocument e, quando tento pesquisar a diferença ou os benefícios deles, não consigo encontrar algo útil. Por favor, diga-me por que você usaria um sobre o outro?

    Se você estiver usando o .NET versão 3.0 ou inferior, será necessário usar o XmlDocument também conhecido como API clássica do DOM. Da mesma forma, você encontrará algumas outras APIs que esperam isso.

    Se você tiver a escolha, no entanto, eu recomendo completamente usando XDocument também conhecido como LINQ para XML. É muito mais simples criar documentos e processá-los. Por exemplo, é a diferença 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); 

    e

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

    Espaços de nomes são muito fáceis de trabalhar no LINQ to XML, diferente de qualquer outra API XML que já vi:

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

    O LINQ to XML também funciona muito bem com o LINQ – seu modelo de construção permite que você construa elementos com sequências de subelementos muito facilmente:

     // Customers is a List 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 )); 

    É tudo muito mais declarativo, o que se encheckbox com o estilo geral do LINQ.

    Agora, como Brannon mencionou, essas são APIs na memory, em vez de streaming (embora XStreamingElement ofereça suporte a saída lenta). XmlReader e XmlWriter são as formas normais de streaming de XML no .NET, mas você pode misturar todas as APIs até certo ponto. Por exemplo, você pode transmitir um documento grande, mas usar o LINQ para XML posicionando um XmlReader no início de um elemento, lendo um XElement dele, processando-o, passando para o próximo elemento, etc. Há várias postagens de blog sobre isso técnica, aqui está uma que eu encontrei com uma pesquisa rápida .

    Estou surpreso que nenhuma das respostas até agora mencione o fato de que o XmlDocument não fornece informações de linha , enquanto o XDocument (através da interface IXmlLineInfo ).

    Isso pode ser um recurso crítico em alguns casos (por exemplo, se você deseja relatar erros em um XML ou controlar onde os elementos são definidos em geral) e é melhor estar ciente disso antes de começar a implementar com XmlDocument , para mais tarde descobrir que você tem que mudar tudo.

    XmlDocument é ótimo para desenvolvedores familiarizados com o modelo de object XML DOM. Já existe há algum tempo, e mais ou menos corresponde a um padrão W3C. Ele suporta navegação manual, bem como seleção de nó XPath .

    XDocument alimenta o recurso LINQ to XML no .NET 3.5. Faz uso pesado de IEnumerable<> e pode ser mais fácil de trabalhar em C # direto.

    Ambos os modelos de documento requerem que você carregue todo o documento na memory (ao contrário do XmlReader por exemplo).

    XDocument é da API LINQ para XML e o XmlDocument é a API padrão do estilo DOM para XML. Se você conhece bem o DOM e não quer aprender LINQ to XML, vá com XmlDocument . Se você é novo em ambos, confira esta página que compara os dois e escolha qual deles você gosta mais.

    Acabei de começar a usar o LINQ para XML e adoro a maneira como você cria um documento XML usando a construção funcional. É muito legal. DOM é desajeitado em comparação.

    Como mencionado em outros lugares, sem dúvida, o Linq to Xml torna a criação e a alteração de documentos XML muito mais fácil do que o XmlDocument , e a syntax XNamespace ns + "elementName" facilita a leitura ao lidar com namespaces.

    Uma coisa que vale a pena mencionar para xsl e xpath é que é xpath 1.0 ainda executar expressões arbitrárias do xpath 1.0 no XNodes Xml do Linq 2 incluindo:

     using System.Xml.XPath; 

    e então podemos navegar e projetar dados usando xpath por meio desses methods de extensão:

    • XPathSelectElement – Single Element
    • XPathSelectElements – Conjunto de Nó
    • XPathEvaluate – Escalares e outros

    Por exemplo, dado o documento Xml:

       10 baa baa 20    Text 1Text 2   

    Nós podemos avaliar:

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

    Além disso, observe que o XDocument é suportado no Xbox 360 e no Windows Phone OS 7.0. Se você os direcionar, desenvolva para XDocument ou migre de XmlDocument .

    Além do comentário acima, o mesmo se aplica ao construir projetos Unity3D para o Windows 8. Você precisará usar o XDocument neste cenário também.

    Eu acredito que o XDocument faz muito mais chamadas de criação de objects. Eu suspeito que, quando você está lidando com muitos documentos XML, o XMLDocument será mais rápido.

    Um lugar que isso acontece é no gerenciamento de dados de varredura. Muitas ferramentas de varredura geram seus dados em XML (por razões óbvias). Se você precisar processar muitos desses arquivos de verificação, acho que terá um desempenho melhor com o XMLDocument .