The <asp:LinqDataSource> control is an ASP.NET control
that implements the DataSourceControl
pattern introduced with ASP.NET 2.0. It is similar to the
ObjectDataSource and SqlDataSource controls in that it can be used to
declaratively bind other ASP.NET controls on a page to a datasource.
Where it differs is that instead of binding directly to a database (like the
SqlDataSource) or to a generic class (like the ObjectDataSource), the
<asp:linqdatasource> is designed to bind against a LINQ enabled data
model.
One of the benefits of using the <asp:linqdatasource>
control is that it leverages the flexibility that LINQ based
ORMs provide. You don't need to define custom
query/insert/update/delete methods for the datasource to call - instead you can
point the <asp:linqdatasource> control at your data model, identify what
entity table you want it to work against, and then bind any ASP.NET UI control
against the <asp:linqdatasource> and have them work with it.
For example, to get a basic product listing UI on my page
that works against Product entities within a LINQ to SQL data model, I could
simply declare a <asp:linqdatasource> on my page that points to my LINQ
to SQL datacontext class, and identify the entities (for example: Products) in
the LINQ to SQL data model I want to bind against. I could then point a
GridView at it (by settings its DataSourceID property) to get a grid-like view
of the Product content:
Figure 2

Without having to-do anything else, I can run the page and
have a listing of my Product data with built-in support for paging and
sorting over the data. I can add a edit/delete button on the Grid
and automatically have update support as well. I don't need to add any
methods, map any parameters, or write any code for the <asp:LinqDataSource>
to handle both these querying and updating scenarios - it can work against the
LINQ to SQL data model we point it against and do these operations
automatically. When updates are made, the LINQ to SQL ORM will
automatically ensure that all business rules and validation logic we've added
(as partial methods) to the LINQ to SQL data model pass before persisting
anything to the database.
Important: The beauty of LINQ and LINQ to SQL is that it
obviously isn't tied to being used only in UI scenarios - or with particular UI
binding controls like the LinqDataSource. As you've seen in my previous
posts in this series, writing code using the LINQ to SQL ORM is extremely
clean. You can always write custom UI code to directly work against your
LINQ to SQL data model if you prefer, or when you find a UI scenario that isn't
particularly suited to using the <asp:linqdatasource>.
The below sections walkthrough using LINQ to SQL and the
<asp:LinqDataSource> control to build the web application scenario I defined
above.
Step 1: Define our Data Model
We'll begin working on the application by first
defining the data model we'll use to represent our database.
I discussed how to create a LINQ to SQL data model using VS
2008's LINQ to SQL designer in Part 2 of this series. Below is a screenshot of the
data model classes I can quickly create using the LINQ to SQL designer to model
the "Northwind" sample database:
Figure 3

We'll revisit our data model in Step 5 of
this tutorial below when we add some business validation rules to
it. But to begin with we'll just use the above data model as-is to build
our UI.
Step 2: Creating a Basic Product Listing
We'll start our UI by creating an ASP.NET page
with a <asp:gridview> control on it and use some CSS to style it:
Figure 4

We could write code to programmatically bind our data model
to the GridView (like I did in Part 3 of this series), or alternatively I could use the
new <asp:linqdatasource> control to bind the GridView to our data
model.
VS 2008 includes build-in designer support to make it easy to connect up our GridView (or any other ASP.NET server
control) to LINQ data. To bind our grid above to the data model we
created earlier, we can switch into design-view, select the GridView, and
then select the "New Data Source..." option within the "Choose
Data Source:" drop-down:
Figure 5

This will bring up a dialog box that lists the available
datasource options to create. Select the new "LINQ" option in
the dialog box and name the resulting <asp:linqdatasource> control you
want to create:
Figure 6

The <asp:linqdatasource> designer will then display
the available LINQ to SQL DataContext classes that your application can use
(including those in class libraries that you are referencing):
Figure 7

We'll want to select the data model we created with the LINQ
to SQL designer earlier. We'll then want to select the table within our
data model that we want to be the primary entity for the
<asp:linqdatasource> to bind against. For this scenario we'll want
to select the "Products" entity class we built. We'll also want
to select the "Advanced" button and enable updates and deletes for
the datasource:
Figure 8

When we click the "Finish" button above, VS 2008
will declare a <asp:linqdatasource> within our .aspx page, and update the
<asp:gridview> to point to it (via its DataSourceID property). It
will also automatically provide column declarations in the Grid based on the
schema of the Product entity we choose to bind against:
Figure 9

We can then pull up the "smart task" context
UI of the GridView and indicate that we want to enable paging, sorting, editing
and deleting on it:
Figure 10

We can then press F5 to run our application, and have a
product listing page with full paging and sorting support (note the paging
indexes at the bottom of the grid below):
Figure 11

We can also select the "edit" or
"delete" button on each row to update the data:
Figure 12

If we flip into source view on the page, we'll see that the
markup of the page contains the content below. The
<asp:linqdatasource> control points at the LINQ to SQL DataContext we
created earlier, as well as the entity table we want to bind against. The
GridView then points at the <asp:linqdatasource> control (via its
DataSourceID) and indicates which columns should be included in the grid, what
their header text should be, as well as what sort expression to use when the
column header is selected.
Figure 13

Now that we have the basics of our web UI
working against our LINQ to SQL data-model, we can go ahead and further
customize the UI and behavior.
Step 3: Cleaning up our Columns
Our GridView above has a lot of columns
defined within it, and two of the column values (the SupplierID and the
CategoryID) are currently foreign-key numbers -- which certainly isn't
the ideal way to represent them to an end-user.
Removing Unnecessary Columns
We can start cleaning up our UI by deleting a
few of the columns we don't need. I can do this in source mode (simply
nuke the <asp:boundfield> declarations) or in designer mode (just click
on the column in the designer and choose the "Remove" task).
For example, we could remove the "QuantityPerUnit" column below and
re-run our application to get this slightly cleaner UI:
Figure 14

If you have used the <asp:ObjectDataSource>
control before and explicitly passed update parameters to update methods (the
default when using DataSet based TableAdapters) one of the things you know can
be painful is that you have to change the method signatures of your
TableAdapter's update methods when the parameters based by your UI are
modified. For example: if we deleted a column in our grid (like above),
we'd end up having to modify our TableAdapter to support update methods without
that parameter.
One of the really nice things about the <asp:LinqDataSource>
control is that you do not need to-do these types of changes. Simply
delete (or add) a column from your UI and re-run the application - no
other changes are required. This makes changing web UI built using the
<asp:LinqDataSource> much easier, and enables much faster
scenarios iterations within an application.