The Moth

Another LINQ implementation that will ship with Fx 3.5 is LINQ to DataSet (not to be confused with LINQ to SQL).

LINQ to DataSet is about offering a strongly typed in-memory query language for DataSets - it is not for creation of DataSets or for smoothly updating the back end. So, if you are already using DataSets in your applications (inc. mobile applications), keep on reading.

If you tried LINQ to DataSet before Beta 2, then you had to reference System.Data.Entity.dll. This assembly is where the new Entity model lives, which will not ship at the same time as VS2008, but instead will ship soon after. Since LINQ to DataSet will ship with VS2008, its implementation had to be relocated. Its new home is System.Data.DataSetExtensions.dll (and it has a bunch of new types and members compared to the pre-Beta2 implementation!).

In this new assembly you will find a single namespace (System.Data) that contains a total of 9 types. Of these 9 types, 6 are used by the infrastructure and are not intended by direct explicit use by you. I have captured these 6 in this class diagram here. Now, think about what you need in order to use the LINQ syntax with the DataSet... not much really. Since DataSet is an in-memory object, the existing implementation of LINQ to Objects is heavily leveraged. However, in order to make things as friendly as possible, some helper intermediate types are used when we compose our queries and when generating strongly typed datasets – as application developers we don't have to worry about them. These intermediaries is what the previous class diagram shows.

When typing your LINQ queries, you have to sometimes convert from the types that the DataSet uses (e.g. a strongly typed DataTable) to types that LINQ likes using (e.g. IEnumerable). Combine that point with the fact that your queries are likely to be at the DataRow or DataTable level and you realise that what you need is some extension methods to help. That is what the remainder 3 types in the assembly are there for, and you should familiarise yourself with those extension methods to make the best of LINQ to DataSet. Use the following class diagram as food for thought before delving into the code:

For example, calling AsEnumerable on a DataTable makes it fit and compile under the query pattern. For example, calling AsDataView on the results of a query, gives you something you can databind a grid with, make changes and then use for updating the back end (a bit of a roundabout way, but it works). For example, rather than use strings and casting and have to deal with nulls at runtime, you can use Field to do the casting for you and convert to a nullable type. See the following quick example that assumes you have a dataset with data and a datagridview on a form:

var results = 
    from o in dataSet1.Tables[0].AsEnumerable()
    where o.Field<string>("City" ) == "Hove"
    select o;

dataGridView1.DataSource = results.AsDataView();

For more background on LINQ to DataSet, see this 3-part series written on the ADO.NET blog back in February: Part one, part two and part three.

There is also a recorded webcast from May which you can view on-demand here. The first 3 minutes are good for setting the scene of why LINQ-enabling the DataSet is important. The following 17' is a generic intro to LINQ so if you are familiar already feel free to skip. From the 20th to the 40th minute are 3 demos where you can see it in action. I'd suggest stop watching after that (i.e. miss the 4th demo) because the feature it shows is not implemented like that in Beta 2 and later. To get the 3 aforementioned demos, visit Erick's blog (and stay tuned there for updates to the LINQ to DataSet story).