Leon points out some LINQ love. Well, the article may be great, but I'm a bit more torn on the technology itself.

The computer scientist part of me finds this very cool from an implementation perspective. The combination of anonymous types, lambda expressions, method extensions and a bit of compiler magic is a really neat do all of this.

On the other hand, I'm still not sure I see the practical side of things. I cringe when I think of all the query logic that is going to be embedded in code. Actually, from this perspective my real problem is with DLINQ, not the LINQ syntax itself. That is, I really have no problem with a syntactic nicety on in-memory objects, I'm just a little more concerned when your code is so tied to an external data source.

Yes, having the query as typed objects in code is better than having the query as a string. But really isn't the goal not to have the query in there at all? This is just terrible practice for any enterprise development. There is a reason we have tiered architectures - because we want abstraction between the levels. The DataSet, while perhaps a bit heavyweight, has proven to be a great means to handle these abstractions.

Rather than integrating queries into the C# language, I would prefer something that promoted a more formal separation of code and query. We've gone through great lengths to do this with a metabase framework that externalizes the query.

Of course, the other aspect of this is that Yukon will host the CLR. LINQ in the database itself is a but more intriguing. It's about time we found a better, strongly-typed alternative to SQL.