5

In my Silverlight application I'm using mostly XmlReader but I'm playing with idea to replace XmlReader implementation with LINQ to XML.

What are pros and cons between LINQ to XML and XmlReader in Silverlight?

John Saunders
  • 160,644
  • 26
  • 247
  • 397
Vadim
  • 21,044
  • 18
  • 65
  • 101
  • 2
    Do you have any reason to believe that the pros and cons would be different for Silverlight? – John Saunders Jul 20 '09 at 16:22
  • I don't think there would be any differences inherent to Silverlight. Rather, what are the differences between the two approaches irregardless of the hosting technology? – Scott Marlowe Jul 20 '09 at 16:26

3 Answers3

8

I would just use LINQ to XML in Silverlight.

The one advantage that XmlReader has over LINQ is that it doesn't build a DOM in memory but rather moves over an existing stream. However this difference only really comes into its own if you can start processing the stream as its arriving rather than waiting for the entire content to arrive. This advantage is quite difficult to acheive and only rarely useful.

LINQ to XML is much more straight forward to query and considerably more flexiable to use, the trade off is some extra memory.

AnthonyWJones
  • 187,081
  • 35
  • 232
  • 306
  • 1
    Microsoft documents an approach of streaming LINQ to XML input/output instead of loading the entire DOM in memory: http://msdn.microsoft.com/en-us/library/system.xml.linq.xstreamingelement.aspx?lc=1033 – Michael Aug 15 '11 at 03:44
  • @Michael: That looks great however I'm not sure how in Silverlight you would use that in a Reader scenario, I can see it would be very useful when writing large amounts of xml. – AnthonyWJones Aug 15 '11 at 12:26
  • You're right that XStreamingElement is intended for streaming xml output, but the third example in the help file documents an approach of using XmlReader, XElement.ReadFrom and c# yield to stream input. Here's a blog post from Microsoft's XmlTeam with more details: http://blogs.msdn.com/b/xmlteam/archive/2007/03/24/streaming-with-linq-to-xml-part-2.aspx – Michael Aug 15 '11 at 20:54
  • @Michael: Thats also a nice technique but Silverlight's implementation doesn't support `ReadFrom` and the question is really about whether to replace XmlReader, ultimately for shear performance and minimal memory footprint XmlReader will be better. – AnthonyWJones Aug 15 '11 at 21:23
  • According to the documentation ReadFrom is supported in Silverlight http://msdn.microsoft.com/en-us/library/system.xml.linq.xnode.readfrom%28v=VS.95%29.aspx (XElement inherits from XNode). But I agree XmlReader is faster and uses less memory than the linq to xml approach, I just wanted to add a small comment to your answer mentioning that you don't have to wait for the entire content to arrive and can process smaller chunks of xml as it arrives. – Michael Aug 16 '11 at 06:30
4

PROs of Linq to XML

  • Query XML documents with the same LINQ syntax your used to
  • Uses the same X objects that you're used to working with (XElement, etc.)

PROs of using XmlReader

  • Finer grain control over the query syntax (XPath rather than LINQ)

...personally, I switched to LINQ to XML when it was first introduced and never looked back. Haven't noticed any significant performance degradation as of yet.

Justin Niessner
  • 242,243
  • 40
  • 408
  • 536
2

LINQ to XML is easier however it requires referencing in System.XML.Linq which increases the number of assemblies your Silverlight application will need to load in. so depending on your situation and your feeds, it sometimes is useful to use XMLReader.

Ricky Brundritt
  • 21
  • 1