LINQ

I did a little project for my wife this weekend and used LINQ for the first time. Visual Basic's implementation of LINQ over XML is just about the greatest thing since sliced bread.

Looking at my Web Updater, I get an xml file called the "wum" (web update manifest, which contains a list of server-side files to compare against a client for making decisions about which files to update). To read these wum.xml files in my Web Updater, I was using an XMLReader to simply parse the file in a serial fashion. Which worked fine, really; although there was not any "knowledge" of the xml document itself within the IDE or the Web Updater code, per se; the parsing routine was a bunch of XMLReader.Read statements, with the occasional variable assignment thrown in whenever certain nodes were reached. Without any prior knowledge of the XML file in question, the parsing process is not exactly intuitive to behold, let alone modify/debug.

With LINQ, this task of reading the wum.xml to determine which files on the disk require an update can be accomplished in a radically different fashion.

First of all, rather than simply associating a wum.xsd schema with the XMLReader's xml settings, you can drop said schema into the solution explorer / project itself and in doing so, define an XML type much in the same way you'd define any given class. With the xml schema now available to the compiler, VB provides you with "xml intellisense", allowing you to traverse an xml document in no less than xml statements such as objMyDocument.<customer>.<name>.<first>.Value and things of that nature. It's a little strange at first but pretty fantastic. This obviously injects a great deal more knowledge of the xml structure itself into the code - now someone viewing or even editing this code for the first time has a far less abstract situation on their hands.

If that weren't enough of an improvement, I realized I didn't really have to serially process the wum.xml at all. I can take that XMLReader I'd been using to create an Xml.Linq.XDocument. An XDocument is basically an xml document instance but it's queryable by LINQ - so you can treat it like a database. Now I can save literally dozens of XMLReader calls & parsing effort by simply querying the XDocument Where Not IO.File.Exists OrElse IO.File.LastWriteTime <> (queryResult.LastWriteTime) and viola, an IEnumrable object of XElements matching the query are returned. In addition, the query result can be stuffed into any given appropriate class of your choosing, so you don't even have to deal with XElements in the result set if you don't want to, and then ultimately .ToList(ed) into a generic List(Of <whatever>).

It's all slightly mind-blowing the first time you sit down to use it, particularly when you consolidate 50 lines of mundane XML parsing into a single LINQ query in a matter of minutes, never even having used LINQ before. Just imagine what you can do with this stuff once you actually know how to use it... pretty cool!