Thursday, October 08, 2009 9:28 PM Sean Feldman

LINQ to XML for Better Maintainability

Today I was trying to solve a simple technical problem. Given a specific XML, needed to clean it up by removing any elements of a particular type.

<Attachment>
  <Name>file1.pdf</Name>
  <Id>1</Id>
</Attachment>
<Attachment>
  <Name>file2.pdf</Name>
  <Id>2</Id>
</Attachment>

Result had to be without Id elements

<Attachment>
  <Name>file1.pdf</Name>
</Attachment>
<Attachment>
  <Name>file2.pdf</Name>
</Attachment>

A few choices for implementation:

  1. Regex
  2. XmlDocument
  3. LINQ to XML
  4. XSLT (as suggested in comments)

Regex option is probably the most efficient, but not the most maintainable. Myself, looking sometimes at the solutions with Regex I ask “what the heck did I try to do here”. So much for “code doesn’t lie”.

XmlDocument is more expressive than Regex option, but way too chatty.

LINQ to XML same as XmlDocument, expressive. As well as very clear and fluent. I picked this option not for performance, but for maintainability sake. I know it will take less developer type to understand and/or modify code when it’s time to change it. And it documents itself very well, with no need to write any comments.

var xdoc = XDocument.Load(new StringReader(received_content));
xdoc.Descendants().Where(element => element.Name == "Id").Remove();
return xdoc.ToString();

 

 

 

Note: this is a very specific case, which does not indicate it’s a solution to all kinds of problems. Regex / XmlDocument are valid tools for all sorts of other problems.

Filed under:

Comments

# Twitter Trackbacks for LINQ to XML for Better Maintainability - sfeldman.NET [asp.net] on Topsy.com

Friday, October 09, 2009 2:09 AM by Twitter Trackbacks for LINQ to XML for Better Maintainability - sfeldman.NET [asp.net] on Topsy.com

Pingback from  Twitter Trackbacks for                 LINQ to XML for Better Maintainability - sfeldman.NET         [asp.net]        on Topsy.com

# re: LINQ to XML for Better Maintainability

Friday, October 23, 2009 6:38 AM by Koen De Waele

Why not using an xslt sheet for this?

// Load the style sheet.

XslCompiledTransform xslt = new XslCompiledTransform();

xslt.Load("output.xsl");

// Execute the transform and output the results to a file.

xslt.Transform("input.xml", "output.xml");

and with the following xslt (from top of my head, check for errors)

<xsl:template match="/">

<xsl:apply-templates select="Attachment">

</xsl:template>

using an xslt shields your code better from changes in xml formats (and thus makes it more maintainable, even for non-developer types :-)).

<xsl:template match="Attachment">

<xsl:copy-of select="Name">

</xsl:template>

# re: LINQ to XML for Better Maintainability

Friday, October 23, 2009 9:05 AM by Sean Feldman

Koen,

Thank you for the suggested option. In case you compare the code snippet I have showed (3 lines) and the code (and I consider XSLT to be a part of code as well), this is already more work. On top of that, now your logic is distributed in code (C#) and XSLT. Planning for future changes when you have even indication that is going to happen is a waste. I try to keep in mind YAGNI principle. When a day comes, and requirements change, I will refactor not only code, but also the design, if needed. Over-designing a simple implementation can have nasty outcomes... KISS is more appropriate in this case.

# re: LINQ to XML for Better Maintainability

Monday, October 26, 2009 1:25 PM by Bill Sorensen

I think you made the right decision with LINQ to XML. I would seldom even consider using a regular expression to parse XML in a production application. Regex's are a great solution to a particular class of problems; parsing XML/HTML is not in that class. Using a DOM parser as you did will work in every case, even edge cases (nested tags, entities, etc.).

And I've gone down the XSLT rabbit-hole before. While it has its uses, it left me with a complex, difficult to read stylesheet that no one else wanted to maintain.