Data Binding Controls
ASP.NET Whidbey provides several options for binding to data. You've already seen the SiteMapDataSource, XmlDataSource, and DataSetDataSource controls in use, but these are just a few of the different data sources provided by ASP.NET for use in Web pages. You can drag each of the controls discussed in the following paragraphs from the Data
tab of the Toolbox window to any page, and you can bind just about any ASP.NET server control to any of these data sources.
The SqlDataSource control allows you to retrieve data from SQL Server, much as the SqlDataAdapter control did for you in earlier versions of ASP.NET. The real difference is that this control encapsulates both the connection and the command information (whereas the older controls required a separate connection control). You'll find that this control makes it easy to create the SELECT
command, and you can then automatically generate the INSERT
, and UPDATE
commands. You have the option of inferring parameters, and can specify how and when the parameter values get fulfilled. Finally, you also have the option of retrieving the schema at design time or at runtime. (Note that the SqlDataSource control uses OLE DB by default, just like the similar controls in the previous version of Visual Studio .NET. You can modify this behavior by tweaking the connection string yourself in the page's source.)
control allows you to set up a data source that retrieves its data from an XML stream. You can specify an XML file name, and can optionally specify an XSL transform, so that you can transform the data before binding it to a control. For example, you may need to transform the raw XML before binding it to a TreeView control. You can also specify an XPath query, so that you can filter the data that's returned from the data source.
control makes it easy to bind to an existing DataSet. Of course, because the DataSet is serialized as XML, this means you can also use the DataSetDataSource control to bind other controls to XML. Unlike the XmlDataSource control, the DataSetDataSource control does not allow you to perform XSL transforms or XPath queries on the XML data.
The ObjectDataSource control will turn out to be, we're guessing, one of the most exciting new data binding features in this release of .NET. This control will make all the n-tier purists out there happyfinally, you can bind the user interface to middle-tier objects, as opposed to DataSet objects directly. This control allows you to specify the name of a class and the name of a method within that class that returns a DataSet. We intend to spend a lot more time investigating the possibilities of this control, as we work with later versions of the product.
The AccessDataSource allows you to retrieve information from an Access database. (Actually, MDB files are databases provided by the Jet database engine. Microsoft Access has little to do with it besides being the major consumer of databases created using the Jet database engine, but the name continues to stick.) This control allows you to specify the name of the Access file instead of having to use an OLEDB provider. Otherwise, the control works just like the SqlDataSource control.
The SiteMapDataSource control allows you to treat a site map as a data source for other controls (most specifically, the TreeView control, as you've already seen). This control retrieves data from a special XML file named app.sitemap
. The XML file has a very specific schema associated with it, so you must be careful to follow the rules. The following code shows an example from the default Intranet Site template: You can see the Home and the Sales nodes in this XML, and those are the nodes that show up in the upper-left corner of the master page in the default Intranet site:
<?xml version="1.0" encoding="utf-8" ?>
<siteMapNode title="Home" url="default.aspx">
<siteMapNode title="Sales" url="Sales.aspx" />
It looks to us like the ASP.NET team at Microsoft has spent a great deal of time looking at the kinds of sites people create. They've done a great job encapsulating much of the common code and functionality into server controls, so developers can spend more of their time on designing great sites and less on rebuilding components other developers also have to build. From the ability to create master pages that define the look of an entire site, to the new security and personalization controls, to the simpler data sources, we're totally impressed with what we've seen in the new version. We can hardly wait to get started building applications using all these new toys. One thing's for sure: sites we build using ASP.NET Whidbey require a lot less code than those we wrote for earlier versions. And that's a good thing.