MIX07 Update: LINQ finally brings OR Mapping to .NET

I mentioned in my last post that the recommendation for dynamic data controls was to use the LINQ data source, and that it had better be good in order to handle all the different types of data sources, object collections and heterogeneous data objects we as developers might want to use.

The good news is that the last session I saw today was on LINQ and in general I was very impressed. It's exactly what .NET developers have been missing since ADO.NET came out ages ago. Java has had decent (if not perfect) O/R mapping libraries for years both in commercial products (TopLink for example) and open-source (Hibernate for example). In the .NET world, there have been some modest attempts at open-source O/R mapping layers (NHiperbate, Gentle.NET, etc.) but because ADO had such a stranglehold on the developer culture they never have flourished. ADO.NET as an O/R mapping layer has been very weak since day one - its more of a basic table gateway pattern than a full O/R mapping layer.

Enter LINQ to the rescue. Here is what I saw demonstrated today:

1. In C# 3.0 or VB 9.0 (shouldn't they reconcile these version numbers at some point), declarative SQL like commands are embedded into the language allowing for strongly typed variables, mapped objects and a SQL query type language.

2. LINQ can currently map to objects, SQL Server, and XML. This might be limiting for the non-Microsoft databases (Oracle, ODBC, Sybase, etc.) but I would expect these to be vendor provided at some point in the future.

3. Based on what I saw, performance looks pretty good in terms of the SQL produced by the layer. One of the smart things that the code does is that it doesn't actually execute until the list of objects is iterated allowing for the combination of queries, filters, etc. that doesn't actually hit the database until you grab the final result set. This allows LINQ to optimize joins, sorts, group by, etc. based on all the combined SQL queries you join together. In addition, parent/child relationships and how they are loaded is configurable based on the context, so you can decide whether it makes sense to lazy load or pre-load your child objects based on your performance needs.

4. Object mapping is done as pure value objects which allows for good separation between the data layer and your domain. So for example, you can define an order object which has nothing but properties and then use either XML, SQL or any IEnumerable collection to load a list of those objects.

5. There is an included designer which allows for code generated classes from existing stored procedures, tables, views and functions. Stored procedures can be assigned for selection, inserts, updates and deletes. If a stored procedure isn't specified, then LINQ will generate the SQL for CRUD operations dynamically. From what I could see in the log, the generated SQL was as it would be expected.

The bad news - LINQ is just in Beta 1 and isn't arriving in final until the next version of Studio 2005 (2007? 2008?) In addition, using LINQ will require at least .NET 3.0 and maybe 3.5, so it will require a framework upgrade to use it.

In general, I was pretty impressed - if Microsoft had this type of technology a few years ago then they would have smoked J2EE before it even got started. In general, they have recognized that the road to developer productivity is to simplify the middle tier. LINQ looks to go a long ways to reduce the amount of basic plumbing required to persist data whether its to an object collection, XML file or SQL database.