I've been talking to a lot of people about LinQ and LinQ to SQL lately and always had trouble explaining them the difference between those concepts. So, obviously I could simply point you to ScottGu's posts on LinQ and Linq to SQL, but that would be cheap wouldn't it?
So, what is LinQ in the first place? People usually mix it up with LinQ to SQL and see it as a new syntax to query databases (but that's LinQ to SQL).
In a nutshell, LinQ stands for Language integrated Query and is a great way to retrieve objects from lists, arrays etc.
Basically, LinQ works an everything that implements IEnumerable, so it's quite safe to say that it works with every .NET collection out there ;).
So, the magic?
LinQ consists of 2 things.
First: By importing the System.LinQ namespace you get some extension methods for your collections.
The above screenshot shows some of the extension methods you get by importing System.LinQ.
Those methods are very useful when working with collections and have become something I won't want to miss.
Here are my most used ones:
Select: Takes a lambda and returns an IEnumerable<> of all items that match the lambda.
This statement will only return an IEnumerable with Tigraine and Tig.
Single: I love this one! Takes a lambda and returns the single item matching the lambda (failing if there is more than one).
This really shines when doing stuff with unique id's.
Any and All: Any checks if one or more items of the collection match the lambda, and All returns true if all items in the collection match the lambda.
So, besides all those great overloads the LinQ namespace provides the real magic is a query like this:
Needless to say that this query syntax works on every collection of objects and provides a great strongly typed query syntax for objects.
LinQ to SQL
So, now that we know what LinQ is we could easily go ahead and write tons of boilerplate code that maps objects to database tables etc etc.. And then use LinQ to query all those objects we created.
But that wouldn't ever work, because having the whole database in memory won't work on any fairly large db. So LinQ to SQL jumps in on this.
LinQ to SQL consists mainly of a graphical OR/M designer in Visual Studio 2008 that allows you to simply drag and drop tables from your database to create the mappings.
Once the mappings are created LinQ to SQL provides you with a DataContext class that represent the objects in your database.
The Users table from my database to the left result in a new collection in your data context called Users that can be queried either through extension methods or through the query syntax.
What happens under the hood is that LinQ to SQL translates your LinQ query into SQL. The generated queries can be viewed while debugging:
The difference to normal LinQ is that LinQ to SQL gets executed once you are using the query data, not when doing the query. The query definition is just the generation of the SQL, while a foreach(var u in users) would actually trigger the query.
And, obviously LinQ to SQL also handles changes to the database through transactions. You just need to modify a value and hit dbContext.SubmitChanges() and LinQ packs any changes back into your database.
LinQ is a clever way to query objects in memory.
LinQ to SQL is a new strong OR/M that takes advantage of the new query syntax and extending it to a database.
This post was never intended to be an exhaustive write-up about LinQ and LinQ to SQL, if you want to know more about those two please refer to ScottGu's posts.