Thursday, June 25, 2009

My experiences with LINQ (basic use with C#)

So here's how it started:

"Fill an object that consists of lists of other objects that consist of lists of other objects from the database"

Meaning, I have to retrieve data from 4-5 different tables, efficiently and bring it in to my app. My first idea: Iterate through the object and write separate queries that will populate each list, and than iterate through each object in the list and fill that one in turn. The number of transactions would be huge... so not such a great idea. Finally I came to the conclusion that an XML record set
 (SELECT
                itemType AS '@type',
                Id AS 'Id'
FROM MyDataTable WHERE Id = @Id
FOR XML PATH('Item'), TYPE)

with a few of those nested, would be a more sensible approach.

After spending a day linking my tables and selecting which values I need and which are junk, I started with the XML parsing. Of course this can be done in many ways, ranging from straight parsing with XPathNavigator to serialization straight into the object, or even transforming the XML using an XSL transform and than serializing it into an object. All those are fun approaches, but this time I decided that I'll use that handy little tool that Microsoft has: LINQ.

Language-integrated Query they call it. Mainly it's used for writing XML files, and unfortunately most examples are regarding that. Of course, as with anything new that I do, I browsed the net for some examples, and gave up after about 5 minutes, and just started fiddling around with it... Here are my discoveries:

The basic statement to use is:
var vComponents = from item in sampleXML.Descendants("component")
     select item;

this gives you a list of items which you can iterate through with something like:
foreach (var vComponent in vComponents)

you may notice that this is a generic type (var) which is a LINQ free-form variable. In this case vComponents is a System.Linq.Enumerable and the vComponent is an XML container (the inner workings of LINQ are not my main concern).

To extract a value from the XML container you might want to use something like:
int myValue = int.Parse(vComponent.Element("myValue").Value);
Guid myGuid = new Guid(vComponent.Attribute("id").Value);

which is pretty straight forward. The fun thing is that you can than take your node vComponent, and use it as you would with any other XML document, so you can say something like:
var vElements = from item in vComponent.Descendants("Element")
select item;

or even:
string itemName = vElements.Element("ItemInfo").Element("ItemName").Value;

Of course, doing stuff like this with XML is risky, because let's say one of your JOINS from the database yielded some NULL values, so you might want to first check for the element to not be NULL before you query for the value, like:
if (vElements.Element("ItemInfo").Element("ItemDescription") != null)
itemDescription = vElements.Element("ItemInfo").Element("ItemDescription").
Value;

just in case the description field was left NULL.

Of course, you might want to wrap it all up in some try{ ... } catch { ... } statements just to prevent any other nasty errors from popping up.

In conclusion, I guess all I can say is: "XML parsing made easy" using Linq. It's good for iterating through multiple nodes of the same type, but I'd expect some nicer way for it to handle errors (like if a node is non existant, don't throw an error just return a NULL value, like serialization does). Hopefully I'll find some time and write a bit about serialization as well...

alex~

No comments:

Post a Comment