Krehbiel Tech

I'm starting to learn a little bit about LINQ.  I am only doing this because I was starting to learn a little bit about the forthcoming ASP.NET MVC Framework by watching some handy screencasts, and the authors of the framework seem to think that we should all be using LINQ, too, so amidst the discussion of the MVC Framework they throw in quite a lot of tutorials about LINQ.

Based on all the hype built up around it over the years, you'd think that LINQ was the second coming.  It's nice, but it's not quite all that.  To understand what it really is, first let me show you a simple SQL query:

SELECT * FROM customers WHERE state='VA'

This query will return every customer record where the customer's address is 'VA.'  It can't get any simpler than that.

Now you might be wondering why invent LINQ when SQL works just fine?  Well, the problem for us application programmers (as opposed to people writing stored procedures or typing queries into Management Studio) is that we have to do some extra work to send that query to the database and get back results in a manageable format (namely, in a collection of objects instead of a flat stream of bytes).  We have to write code that looks something like this (super-simplified for illustration):

SqlCommand command = CreateCommand( "SELECT * FROM customers WHERE state='VA'" );
SqlDataReader data = command.ExecuteReader();
List<Customer> results = new List<Customer>();
while( data.Read() ) {
Customer customer = new Customer( data );
customers.Add( customer );
}

That will get us a collection of Customer objects that we can work with.  It's not particularly difficult, but it's kind of ugly and awkward.  Normally we try to hide those awkward details behind a data access layer so it doesn't distract us from our application logic.  With the details hidden, we might end up writing application code that looks like this:

IEnumerable<Customer> customers = datalayer.GetCustomersFrom( "VA" );

That worked fine, but now we have a whole new paradigm in LINQ.  Now we don't have to wrap our queries with extraneous code.  Here is the same concept as the above SQL query, written as a LINQ query:

var customers = from c in db.Customers where c.State=="VA" select c;

The cool thing is you can put that right inline with your source code, and what you get back from it is "customers" -- an enumerable collection of Customer objects.

How's it work?  Well, when you get right down to it, it's basically just another data access framework that hides the messy details of querying the database, just like all the other data access frameworks out there.  The only things that are different about this one are, 1) it's built by Microsoft, and, 2) it's integrated right into the language.  (Those are two powerful incentives to use it, by the way.)  But there's nothing really magical about it -- behind the scenes, LINQ to SQL queries are transmogrified into method calls that eventually build SQL statements, send them to the database, instantiate Customer objects, and populate them with results from the query.

But enough of that.  Let's talk about the LINQ query syntax itself.  I find it puzzling.  For example, in LINQ query syntax, we have to specify where to look before we specify what we're looking for.  In SQL, it was a pretty straightforward "select stuff from here."  But in LINQ, it's backwards -- it's "from here, select stuff."

We also have to specify the search criteria in the middle.  In SQL, it was "select stuff from here with this criteria."  In LINQ, it's "from here, with this criteria, select stuff."

Furthermore, we have to reference the name of each row entity, as in "from each row named x in here, select stuff."  I can only speculate that that becomes more of an asset in complex queries, but in my experience, simple queries are much more common than complex queries, so it seems like needless redundancy to me.

In short, LINQ is a handy shortcut if you're working with Microsoft .NET 3.5 technology and nothing else.  (It's almost entirely worthless if you aren't.)  For myself, I can see the benefit in understanding the basics, and I'm sure I'll enjoy working with it where possible, but I can't see myself expending much effort in becoming an "expert" on LINQ.

Cross-posted to http://krehbieltech.blogspot.com/2008/08/linq-query-syntax.html