Microsoft LINQ Books

We just published an updated version of the corrections for the Programming Microsoft LINQ book.

You can download it from this link.

.NET 4.0 will add the concept of Tuples in the Base Class Library, that will improve interoperability between languages such as F# or IronPython and C# or Visual Basic. LINQ will not have big changes in .NET 4.0, but only some lifting to support new features: for example, the Zip operator will be added in System.Linq.Enumerable to combine two collections generating an ordered sequence of Tuples (that you can then project in a different way). Some good examples are described in this post by Matthew Podwysocki.

To make a long story short: the ADO.NET team is now responsible of ADO.NET Entity Framework (including LINQ to Entities) and of LINQ to SQL (the last one was originally in charge of the a separated team, tied to the C# compiler).

There is an evident overlapping between LINQ to SQL and LINQ to Entities and since the first day, Microsoft said that in the long run, these two solutions would have been merged into a single one.
Now, the roadmap that is arising is: Entity Framework will be improved adding features that will be necessary to cover scenarios where LINQ to SQL today is preferred over LINQ to Entities and Entity Framework.

There are a lot of comments - I suggest you starting here to get a good recap and pointers to many others.

My personal opinion is that LINQ to SQL is very good in some scenarios and should not be dropped until a good alternative (in EF?) is available. For example, I use LINQ to SQL to implement nightly processes that are part of ETL solutions. In these cases, I use LINQ to SQL to read data (expecially configuration data, but sometimes also source data) and use the SqlBulkCopy API to write data into destination tables. Having all the necessary into a single executable file, without external dependencies, is a big advantage for deployment (a single file to copy). Today LINQ to Entities would be slower, would have more files and would require .NET 3.5 SP1 on production servers (the last one would not be a real issue in my case). There are of course other scenarios when there is something that makes LINQ to SQL a better choice against the current version of Entity Framework.

My hope is that a convergence of two partially overlapped frameworks is good, but at the same time this shouldn't be a penalization for the current users of the "losing" part. This will require several releases of .NET to be done, and I hope that in the meantime the LINQ to SQL engine will have a decent evolution to keep its current position of "light LINQ oriented DAL replacement to SQL Server".

Today I needed to use SqlBulkCopy class passing an IEnumerable<T> as a source instead of a IDataReader. Before writing something that someone else could have already written, I made some search and I found this interesting post that solve exactly this issue. In the post there is also a link to source code. Take also a look at performance optimization for getter as described in post comment.

Paul Stovell made a presentation on "Reactive Programming and Bindable LINQ" at TechED Australia 2008 (unfortunately, I was at the antipode in Italy, but the topic is really interesting). I didn't know there are projects somewhat similar to Bindable LINQ in CodePlex: Obtics and Continuous LINQ. I really like the idea of defining "live" queries with LINQ.

In the Programming Microsoft LINQ book we dedicated two whole chapters (76 pages) about the writing of a IQueryable LINQ provider: one is about expression trees and the other covers the several ways to extend LINQ, including the writing of an IQueryable provider. I know that the subject is complex and probably is not necessary to every programmer. However, a good understanding of what happens under the cover of an IQueryable provider is good for everyone using any flavor of LINQ: when you debug your code, it might help you in finding issues faster.

I wrote this introduction just to explain why you should read this post of Bart De Smet, which is undoubtedly shorter than the corresponding chapter of our book and gives you a very good step-by-step introduction of the inner workings of an IQueryable LINQ provider. Then, if you really like this kind of things, you have another good reason to read the book :-)

I have just validated this bug posted on Connect. It seems a compiler issue, I'd like to read a Microsoft answer about this.

However, the general issue is that using ArrayList in a lambda expression with a collection initializer could be dangerous. There are not so many reasons to use an ArrayList in a lambda expression, unless you are refactoring or working with legacy code that cannot be modified upgrading ArrayList to generic collections.

I just read a post about getting multiple results with LINQ to SQL without using stored procedures. This technique is interesting when you have multiple queries returning a few rows each one and you want to save time by skipping some roundtrip between your program and SQL Server. Looking at the post, I immediately thought that it would be interesting comparing this solution with an asynchronous one, executing each query in a different thread. I don't have time to make some benchmark, but it would be interesting to make a comparison between these two techniques.