I am a little tired of using the SQL like syntax that is available for LINQ. Don’t get me wrong, LINQ and the language / .Net features introduced to support it in .Net 3.5 are great. I don’t find myself using the SQL to LINQ at all, but I constantly find myself using LINQ with collecitons and XML. After almost a year with the enhancements (in beta version this in GA .Net 3.5), the appeal of the SQL-like syntax has worn off, and I have come to realize that I enjoy using the actual function calls to which this psuedo-SQL-language is mapped.
I think the the SQL-like LINQ syntax was just the sugar to attract attention to LINQ. In practice I have found that it make my code less readable. To a developer that is not intimately familiar with LINQ, a complex expression is completely unintuitive. It is just enough unlike SQL to confuse. When it comes to complex select statements, joins, and other operations that are outside the standard SELECT…FROM…WHERE syntax (or FROM…WHERE…SELECT in LINQ), simply calling the framework functions directly makes more sense to me. It creates code that is easier for C# developers to read. It isn’t pretending to be SQL, and so it becomes much easier to follow what is really happening to anyone that understands enumeration, iteration and delegates. With function chaining, it is also easy to write very clean chunks of code by use of indentation. And when I have to explain the code to another developer that is unfamiliar with LINQ I can simply say, “.Select() is run for each record, .OrderBy() is run on the collection to sort the records, etc”. With the SQL syntax I first must explain the mappings.
I have found myself rewriting old SQL syntax to C#/LINQ when I need to add new functionality. As much as I use LINQ, I still have to look-up how to do certain operations when using the SQL-like syntax, but find it easy to write the same functional code with pure C#/LINQ extension calls.
I admire what the Microsoft .Net team did with LINQ, but I think I will be skipping the SQL syntax from now on.
