views:

705

answers:

2

I have written a WPF application that I want to port to Silverlight 2.

My business logic and model (for the M-V-VM design pattern) are packaged into a separate assembly which I am trying to recast as a Silverlight class library.

Unfortunately, the XmlNode class which I use to parse an XML file with model data is not supported by Silverlight 2. The guidance is to use LING to XML instead (http://silverlight.net/forums/t/14577.aspx). Using LINQ seems overkill to me for my task. I am considering replacing the XML parsing code using the XML DOM with a scheme based on regular expressions (for parsing the attributes). Alternatively, I am considering writing my own implementation of XmlNode which would be referenced in case the project was compiled for Sliverlight 2.

Does anyone have faced a similar sitation? Does anyone have any suggestions (maybe a 3rd option) on how to proceed (RegEx or re-write)?

+2  A: 

Not sure how Linq to Xml is overkill. It is actually much easier to do Xml parsing with Linq2xml once you get the hang of it. I would say that regex or writing your own XmlNode would be overkill.

If you post some of the XmlNode work that you're doing I'm sure you would get some good translations. In the meantime, here is a good introduction to how easy it is to parse documents with Linq to Xml.

Update: In response to the issue being performance, all I could find was that linq to xml is faster than XmlDocument.

Bryant
I should have been a bit more specific. I am concerned with the performace overhead of using LINQ2XML compared to a simple, customized parser. LINQ will use reflection to create instance of anonymous types. Custom code generates instances directly for example.
Philipp Schmid
Unless you have some really bizarre scenario, any overhead from the LINQ methods is pretty negligible. My recommendation would definitely be to go with that instead of doing all of the parsing by hand.
MojoFilter
A: 

The class System.Xml.Linq contains the XML DOM classes like XDocument, XElement, XNode and XAttribute that are way more performant and light-weight to their XmlDocument, XmlElemnt etc counter parts. You can use these classes without using Linq, but with Linq to Xml you can do very interesting things. It is absolutely the way to go!