oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Data Binding in ASP.NET 2.0
Pages: 1, 2, 3

DataSource Controls

The DataSource control provides a single object that you can define either declaratively (in your web page) or programmatically (in your code-behind) that will own the connection information, the query information, and the parameters and the behavior (such as paging and caching). You can then "bind" the object to various UI objects for display on your web page.

Related Reading

ADO.NET in a Nutshell
By Bill Hamilton, Matthew MacDonald

There are a variety of DataSource controls, including controls for accessing SQL from SQL Server, from ODBC or OLE DB servers, from XML files, and from business objects. All of these DataSource controls expose the same properties and methods, and all of them bind to UI objects (such as DataList and GridView) in the same way.

Thus you have a variety of UI controls all binding in the same way to a variety of underlying data sources, and the details (the plumbing) are handled by the DataSource controls for you, greatly simplifying even complex data manipulation tasks in web applications.

ASP.NET 1.x developers will find significant changes (and simplifications) in how your ASP.NET application interacts with underlying data. The ADO.NET object model has been encapsulated in controls, and the details (data sources, tables, relations, and so on) have been pushed down into the framework layer. This frees you from worrying about the details and provides a much more uniform API for interacting with various types of data sources.

Binding Data Controls with Drag and Drop

Now that we have a working DataSource control, let's hook it up to a control to display the data we've retrieved. Drag a GridView onto the page. The GridView recognizes that there is already a SqlDataSource on the page and so does not create its own. Instead, its smart tag opens and asks you to choose your data source, as shown in Figure 5:

Figure 5
Figure 5: Choosing a data source

As soon as you set the data source, the DataGrid is redrawn, with a column for each field returned by the data source. Notice that the column headers have also been filled in for you. Switch to source view, and examine the declaration of the DataGrid. Visual Studio 2005 has done a lot of work for you. It has examined the data source and created BoundField for each column in the data. Further, it has set the HeaderText to the name of the DataField. Finally, you'll notice on the third line of the declaration of the DataGrid that it has set AutoGenerateColumns to false.

If you were creating the DataGrid by hand, and if you were going to let the DataGrid create all the columns right from the retrieved data, you could greatly simplify the code by just setting AutoGenerateColumns to true.

So why bother with turning off AutoGenerateColumns and creating the columns by hand? The answer is that doing so gives you much greater control: you can, for example, set the headings on the columns (for instance, changing ContactTitle to Title), leave columns you don't need, and add new columns for manipulating the rows.

You can make these changes by hand-coding the HTML in the source view, or by clicking on the smart tag for the DataGrid and choosing Edit Columns. Doing so brings up the Fields dialog box, as shown in Figure 6.

Figure 6
Figure 6: Specifying the fields

The dialog box is divided into three main areas: the list of available fields, the list of selected fields (with arrows to remove or reorder the list), and the Bound Filed Properties window on the right. Click on a selected field (such as ContactTitle), and you can set the attributes of how that field will be displayed in the DataGrid (for example, changing the header to Title).

Adding features to the grid

While we're examining what we can do with the DataGrid, click on its smart tag and click on AutoFormat to choose one of the nice formatting options. You can, of course, format it by hand, but why work so hard? I'll choose BrownSugar because it shows up well on this page. While you're at it, click on Enable Sorting. (Hey! Presto! The columns can be sorted.) Run the application. See Figure 7.

Figure 7
Figure 7: The completed grid

Adding Insert, Update, and Delete Statements

The DataSource control that you've created currently has only a Select statement to extract data from the database:

<asp:SqlDataSource ID="SqlDataSource1" 
runat="server" SelectCommand="SELECT * FROM [Customers]" 
ConnectionString="<%$ ConnectionStrings:NorthwindConnectionString %>" />

You can, however, ask your DataSource control to create the remaining three CRUD (Create, Retrieve, Update, and Delete) commands, using a wizard to make your work much easier. Switch to data view, click on the SqlDataSource's smart tag, and choose Configure Data Source. The Configure Data Source wizard opens, displaying your current connection string. Click on Next, and the Configure Select Statement dialog is displayed. Click on the Advanced button, as shown in Figure 8.

Figure 8
Figure 8: Selecting all columns

This opens the Advanced SQL Generation options. This is similar to the Data Adapter wizard in ASP.NET 1.1. Check the Generate Insert, Update and Delete statements check box, as shown in Figure 9.

Figure 9
Figure 9: Advanced SQL generation

Clicking on this check box instructs the wizard to create the remaining three CRUD methods, and it also enables the second check box: Use optimistic concurrency. Do not check this yet. Click on OK, Next, and Finish. You will be asked to update your grid, which unfortunately will wipe out all your careful work setting titles, and so on (is this a beta bug?), but the good news is that you are now bound to a DataSource control that provides all four CRUD methods. Take a look at the HTML generated for the DataSource control. You'll find Delete, Update, and Insert commands, complete with the parameters needed for each command.

Pages: 1, 2, 3

Next Pagearrow