XDocument veya XmlDocument


502

Şimdi öğreniyorum XmlDocumentama yeni koştum XDocumentve aralarındaki farkı veya faydaları araştırmaya çalıştığımda yararlı bir şey bulamıyorum, lütfen neden birini diğerinin üzerinde kullanacağını söyleyebilir misin?


13
Microsoft'taki belge adamlarının neden farklılıklarını veya ne zaman kullanacağını açıklamak için MSDN'de neden herhangi bir not veya açıklama yapmadığını merak ediyorum.
Kamran Bigdely

1
Msdn hakkında bazı bilgiler: msdn.microsoft.com/en-us/library/… . Ve bir performans sorusu: stackoverflow.com/questions/4383919/… . Şahsen LINQ to XML ile çalışmayı daha kolay buldum.
nawfal

Yanıtlar:


500

.NET sürüm 3.0 veya önceki bir sürümünü kullanıyorsanız, diğer bir deyişle klasik DOM API'sini kullanmanız gerekirXmlDocument . Benzer şekilde, bunu bekleyecek başka API'lar da olduğunu göreceksiniz.

Ancak seçim alırsanız, iyice XDocumentaka LINQ to XML kullanmanızı tavsiye ederim . Bu var çok belge oluşturmak ve bunları işlemek için daha basit. Örneğin, aşağıdakiler arasındaki farktır:

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

ve

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

Ad alanları, şimdiye kadar gördüğüm diğer XML API'larının aksine, LINQ to XML'de çalışmak oldukça kolaydır:

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

LINQ to XML, LINQ ile de çok iyi çalışır - yapım modeli, alt eleman dizileriyle öğeleri kolayca oluşturmanıza olanak tanır:

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

Genel LINQ stiline uyan çok daha açıklayıcı.

Şimdi Brannon'un belirttiği gibi, bunlar akışlı olanlar yerine bellek içi API'lerdir ( XStreamingElementtembel çıktıları desteklese de). XmlReaderve XmlWriterXML'de .NET akışının normal yollarıdır, ancak tüm API'ları bir dereceye kadar karıştırabilirsiniz. Örneğin, büyük bir belgeyi aktarabilir, ancak XmlReaderbir öğenin başlangıcında bir konumlandırarak , bir öğeyi okuyarak XElementve işleyerek, ardından bir sonraki öğeye geçerek LINQ'dan XML'e kullanabilirsiniz . Bu teknik hakkında çeşitli blog gönderileri vardır, İşte hızlı bir arama ile buldum .


Bana neden farklı olduklarını söyleyebilir misiniz? Yani XDocument oldukça düzgün görünüyor ama DOM seviyesi farkı gelince, ikisi de xml değil, hem Microsoft X-DOM hem de W3C Uyumlu DOM'u gösteren herhangi bir şema var mı? Teşekkürler.
Tarik

3
"Şema" ile ne demek, "şov" ile ne demek istiyorsun? Evet, ikisi de standart XML ile uğraşıyor, ancak LINQ to XML, çoğu şey için sadece daha hoş bir API. LINQ to XML'in arkasındaki birçok teknoloji .NET 3.5'ten önce mevcut değildi.
Jon Skeet

Yani belge nesne modellerinin farklı olup olmadığı?
Tarik

6
Her ikisi de XML'in kendisi için API'ler, bu yüzden farklı değiller, hayır. Her ikisinin de bazı sınırlamaları olduğundan şüpheleniyorum (ve bildiğim, ancak kafamın üstünü hatırlayamadığım bir LINQ to XML), ancak çoğu durumda bunları biraz farklı sunumlarla aynı model olarak ele alabilirsiniz.
Jon Skeet

1
@SensorSmith: Bu, dizilerin otomatik olarak düzleştirilmesi, DateTime vb. Gibi diğer tüm bonusları kapsamıyor. Bunların tümü için uzantı yöntemleri de ekleyebilirsiniz, ancak bunun yerine neden kullanabileceğinizi LINQ'u XML'e yeniden icat edebilirsiniz?
Jon Skeet

57

Ben cevapların sürpriz hiçbiri bugüne kadar gerçeği bahseder duyuyorum XmlDocumenthiçbir satır bilgi sağlar iken, XDocumentyapar (aracılığıyla IXmlLineInfobir arayüz).

Bu, bazı durumlarda kritik bir özellik olabilir (örneğin, bir XML'deki hataları bildirmek veya öğelerin genel olarak nerede tanımlandığını takip etmek istiyorsanız) ve kullanarak XmlDocumentdaha sonra kullanmaya mutlu bir şekilde başlamadan önce bunun farkında olmanız daha iyi olur hepsini değiştirmek zorunda olduğunuzu keşfedin.


1
Ve kimsenin ifadenizin tersine doğru olduğunu fark etmediğine şaşırdım. XmlDocument satır bilgilerini sağlar, XDocument bunu yapmaz.
VVS

4
@VVS: Korkunç bir yazım hatası yaptığım için bir an için beni endişelendiriyorsun, ancak iki kez kontrol ettikten sonra, XDocumenthat bilgilerini sağladığını onaylıyorum . Bkz XDocument.Load ile LoadOptions.SetLineInfobir parametre olarak verilir. Eğer hat bilgisi almanın bir yolunu biliyorsanız XmlDocumentmerak ediyorum; bu cevabı yazdığımda hiç bulamadım. Bu diğer yanıt onaylıyor gibi görünüyor: stackoverflow.com/a/33622102/253883
Julien Guertault

1
"ve XmlDocument kullanarak mutlu bir şekilde uygulamaya başlamadan önce bunun farkında olsanız iyi olur, daha sonra hepsini değiştirmeniz gerektiğini keşfedebilirsiniz." Tahmin et ne yaptım :)
Paul

36

XmlDocumentXML DOM nesne modelini bilen geliştiriciler için mükemmeldir. Bir süredir piyasada ve az ya da çok bir W3C standardına karşılık geliyor. Manuel navigasyonun yanı sıra XPathdüğüm seçimini de destekler .

XDocument.NET 3.5'te LINQ to XML özelliğini güçlendirir. Ağır C kullanır IEnumerable<>ve düz C # ile çalışmak daha kolay olabilir.

Her iki belge modeli de belgenin tamamını belleğe yüklemenizi gerektirir ( XmlReaderörneğin aksine ).


3
Bence "düz VB.net ile çalışmak daha kolay olabilir" demek istediniz. Çünkü VB, C # 'nin hala kod gerektirdiği öğelerin doğrudan oluşturulmasını destekler.
Brain2000

24

XDocumentLINQ'dan XML API'sına ve XML XmlDocumentiçin standart DOM stili API'dir. DOM'u iyi tanıyorsanız ve LINQ to XML öğrenmek istemiyorsanız, devam edin XmlDocument. Her ikisinde de yeniyseniz, ikisini karşılaştıran bu sayfaya göz atın ve hangisini daha iyi beğendiğinizi seçin.

LINQ to XML kullanmaya yeni başladım ve fonksiyonel yapıyı kullanarak bir XML belgesi oluşturma şeklinizi seviyorum. Gerçekten güzel. Karşılaştırmada DOM tıknaz.


23

Başka bir yerde de belirtildiği gibi, hiç şüphesiz, Linq to Xml xml belgelerinin oluşturulmasını ve değiştirilmesini kıyaslandığında bir esinti yapar XmlDocumentve XNamespace ns + "elementName"sözdizimi ad alanlarıyla uğraşırken keyifli bir okuma sağlar.

Bahsetmeye değer xslve xpathdikkat edilmesi gereken bir şey xpath 1.0, Linq 2 Xml'de keyfi ifadeleri şu şekilde dahil ederek yürütmenin mümkün olduğudur XNodes:

using System.Xml.XPath;

ve sonra xpathşu uzantı yöntemlerini kullanarak verilerde gezinebilir ve yansıtabiliriz :

Örneğin, Xml belgesi verildiğinde:

<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>

Değerlendirebiliriz:

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

14

Ayrıca, XDocumentXbox 360 ve Windows Phone OS 7.0'da desteklendiğini unutmayın . Onları hedeflerseniz, için geliştirin XDocumentveya bu yerden geçiş yapın XmlDocument.


-8

Bunun XDocumentçok daha fazla nesne oluşturma çağrısı yaptığına inanıyorum . Çok fazla XML belgesi işlerken XMLDocumentdaha hızlı olacağından şüpheleniyorum .

Bunun gerçekleştiği yerlerden biri tarama verilerini yönetmektir. Birçok tarama aracı, verilerini XML olarak çıkarır (bariz nedenlerle). Bu tarama dosyalarının çoğunu işlemeniz gerekiyorsa, bence daha iyi bir performansa sahip olacaksınız XMLDocument.


11
Sanırım yanlış olabileceğine inandığım için yorumunuzu bir dahaki sefere rakamlarla desteklemelisiniz. Bkz. Blogs.msdn.com/b/codejunkie/archive/2008/10/08/…
mike
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.