I thought that Linq was just a restating of a SQL statement closer to how the data engine actually looks at your script.
Well, hmmmm..... ;)
LINQ is a set of extensions to the .NET Framework to query different types of data using a common language. Prior to LINQ, if you wanted to write code to query a List collection, you'd have to do it one way - and if you wanted to query a Dataset, you'd have to do it another way - etc....and each method carried challenges and shortcomings.
So you now have LINQ to XML to query XML documents, LINQ to Objects to query arrays, lists, etc. (a HUGE improvement), and LINQ to DataSets to do sql-like joins and queries against DataSets (though if you're going to use Linq to DataSets, you'll be MUCH better off using typed datasets than untyped datasets).
LINQ allows you to write similar syntax to query different types of objects using similar syntax. On the whole, I like LINQ very much. The only thing I'm not crazy about (as of today) is LINQ to SQL. Every other aspect of LINQ is a substantial improvement over what previously existed.
But if someone is going to use LINQ to SQL to write their own SQL syntax to query databases, I don't think it's a big improvement. LINQ to SQL syntax is a little different from your 'traditional' T-SQL syntax. What happens is that LINQ to SQL converts your code to actual T-SQL syntax before passing it on to the data engine. And some of the coverted SQL code is not what you'd write, if you were writing your own stored procedure to begin with.
Now that Beta 2 is out, and is deemed 90-something percent close to what the final product will be, I'm going to publish a list of LINQ to SQL queries and what the resulting SQL code looks like. If you don't have huge databases, maybe it's not that big of a deal, but if you do, it's important to know that LINQ to SQL doesn't always generate the most efficient sql code.
Craig Boyd brought up a good point in a recent post about datasets - sure, they're not always the most efficient animals in the world (though, personally, I think the stated ineffeciencies have been exaggerated by some), but there may not be a better alternative. In this instance, I think there
is a better alternative: just to continue writing stored procedures and not writing in-line LINQ to SQL code.
If you query (no pun intended) .NET developers/database developers outside the Fox world and ask them what they think of LINQ, many are also going to tell you that the other areas of LINQ are really cool....but that they already had a tool for SQL - T-SQL itself!!! ;)
I covered it in a recent issue of CoDe magazine (at the moment, you'll have to be a paid online subscriber to read it, but either way, you can pull down the download code on the first page, which has over 20 code samples):
http://www.code-magazine.com/Article.aspx?quickid=0707051Rick Strahl has some good coverage of LINQ as well in this article:
http://www.code-magazine.com/Article.aspx?quickid=070123Hope that helps...
Kevin
