The application we just described relies on a bindingSource object that exposes an ADO.NET DataTable as a data source. Migrating this application to LiveLinq is very easy. All you need to do is have the bindingSource object expose a LiveLinq view instead of a regular DataTable.

Here are the steps required:

1. Add a reference to the C1.LiveLinq.dll assembly to the project.
2. Add a few using statements to make the code more readable:

   C#	Copy Code
   using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; using C1.LiveLinq; using C1.LiveLinq.AdoNet; using C1.LiveLinq.LiveViews;

    

    

3. Create a LiveLinq query and assign it to the DataSource property of the bindingSource object, replacing the original reference to a DataTable object:

   C#

   Copy Code

   private void Form1_Load(object sender, EventArgs e) { // generated automatically this.productsTableAdapter.Fill(this.nORTHWNDDataSet.Products); this.categoriesTableAdapter.Fill(this.nORTHWNDDataSet.Categories); // Create a live view for Categories. // Each category contains a list with the products of that category. var categoryView = from c in nORTHWNDDataSet.Categories.AsLive() join p in nORTHWNDDataSet.Products.AsLive() on c.CategoryID equals p.CategoryID into g select new { c.CategoryID, c.CategoryName, FK_Products_Categories = g }; // replace DataSource on the form to use our LiveLinq Query this.bindingSource1.DataSource = categoryView; }

The code starts by creating the LiveLinq query that will serve as a data source for all controls on the form.

The query is 100% standard LINQ, except for the AsLive statements which turn the standard LINQ query into a live view suitable for binding. Without them, the code would not even compile.

The query uses a join to obtain all products for each category and store them in a group, and then selects the category ID, category name, and the group of products associated with the category.

The group of products is named FK_Products_Categories. We did not name it something simple and intuitive like “Products” because the binding code created behind the scenes by Visual Studio relies on this specific name.

If you look at the Form1.Designer.cs file, you will notice that Visual Studio created a bindingSource object named fKProductsCategoriesBindingSource which is initialized as follows:

//
// fKProductsCategoriesBindingSource
//
this.fKProductsCategoriesBindingSource.DataMember = "FK_Products_Categories";
this.fKProductsCategoriesBindingSource.DataSource = this.bindingSource1;

This code assumes that the original binding source contains a property named "FK_Products_Categories" that exposes the list of products for the current category. To ensure that the bindings still work, our query needs to use the same name.

If you run the project now, you will see that it works exactly as it did before. But now it is fully driven by a LINQ query, which means we have gained a lot of flexibility. It would be easy to rewrite the LINQ statement and display additional information such as supplier names, total sales, etc.