在本文中，我将引导您浏览ASP.NET 2.0中的主要数据源控件
数据源组件一览
从根本上说，数据源控件就是包装了特定数据源（如SQL Server、Microsoft Access或XML文档）的一些基本函数的服务器控件。这些基本函数包括查询、插入、更新和删除。数据源控件不具有UI并且不呈现任何标记（请注意，有许多控件都不具有UI，然而却呈现标记）。可以用声明方式或编程方式将其绑定到数据控件。通过数据源组件的服务，数据绑定控件除了可以从特定数据源获取数据以外，还可以插入新记录或者更新和删除现有记录。控件的接口总是相同的，无论您使用哪种特定的数据源（即，无论是SQL Server数据库、XML文档、Microsoft Excel工作表还是站点图描述）。
数据源对象是自描述性的，并且能够让绑定控件了解基础数据源中受支持的功能。这样，控件就可以方便地基于它所连接的数据源的功能来调整它自己的用户界面。例如，网格组件可以仅在基础数据源可编辑时才显示Edit列。
数据源控件是ASP.NET 2.0数据绑定模型中迄今为止最为重要的更改。在ASP.NET 2.0中，数据源控件是推荐的用于执行数据绑定的工具。需要注意的是，数据源控件与公开IEnumerable接口的对象一起工作。在数据驱动的应用程序中，数据源控件绝不会取代DataView和数组。而且，可以保证向后兼容性。使用数据源控件，您现在就具有了一种将数据绑定到任何新增和现有数据绑定控件的备用方法。数据源控件不会带来任何性能问题，性能基本与版本1.x中的相同甚至略高一筹。
ASP.NET 2.0向所有数据绑定控件中添加了一个新属性，以便每个控件都可以成功地绑定到数据源控件。应该将这一新属性—DataSourceId—设置为在同一页面中定义的数据源控件的名称。下面的代码片段显示了如何用针对SQL Server数据库执行的查询结果来填充DataGrid控件：
- <asp:SqlDataSource
- runat="server"
- ID="MySource"
- ConnectionString="...;"
- DataSourceMode="DataSet"
- SelectCommand="..."
- />
- <asp:DataGrid
- runat="server"
- ID="data"
- DataSourceId="MySource"
- />
SqlDataSource是公开SQL关系数据库内容的数据源控件。（需要注意的是，SqlDataSource不是特定于SQL Server的，但有关该问题的详细信息留待稍后讨论。）ConnectionString属性标识源数据库，而SelectCommand属性被设置为查询字符串。正如前面所提到的，您可以使用传统的DataSource属性或新的DataSourceId属性将数据传递给数据绑定控件。请注意，这两个属性是互斥的。如果您同时设置这两个属性，将会引发异常。
通过使用数据源控件而不是传统的可枚举对象，您会得到什么呢？首先，您可以在.aspx页中使用一个简单的标记来声明数据源。这样可以实现数据源对象的自动实例化，并减少为完整设置该页面而需要编写的代码数量。您不再需要显式地操纵如SqlConnection和SqlCommand这样的对象。数据源减少了对服务器数据组件（连接、适配器、类型化数据集）的依赖性，这是因为这些组件极度依赖于Visual Studio .NET的代码生成功能。在Visual Studio 2005中，被隔离在don't-change-this-code（不要更改以下代码）区域中的自动生成的代码数量明显减少。这并不意味着要丢弃设计时功能，而是刚好相反。数据源控件促成了控件和数据组件之间的直接和隐式绑定。通过这一体系结构，可以开发智能设计器，以便动态发现架构和数据，从而更为准确地表示数据绑定控件的运行时外观。
至少对于常见方案（如选择、排序、分页、删除和基本更新）而言，您可以通过简单地连接和配置一对控件来设置数据绑定。图2显示了Visual Studio 2005工具箱的Data选项卡。它包含了一些数据源控件和数据绑定控件—您在许多情况下需要涉及的唯一工具。如果是这种情况，您的页面几乎不需要任何数据绑定代码。尽管如此，由于页面需要更为复杂的数据绑定功能，因此需要您添加少量代码。
通过数据源控件，可以在多种数据源中实现一致的绑定模型。（图2中的控件只是将在ASP.NET 2.0发布时可用的控件的子集。）作为页面开发人员，您将使用相同的属性，而无论数据源是关系表（无论是哪种数据库系统）、XML文档、自定义类还是Excel文件。
您通过使用数据源控件而得到的另一项优势与数据缓存有关。许多关于ASP.NET编码策略和优化的书籍和文章都将缓存数据列为构建高性能、可伸缩Web应用程序的最佳做法。毫无疑问，数据缓存意味着关键的性能增强，即使它不是对所有页面和应用程序都有效的魔杖。例如，当您管理大量特定于会话的不稳定数据时，或者当您的要求规定必须始终显示新数据时，广泛使用缓存可能不是最佳的方法。请放心，在大多数情况下，缓存数据都是一种改进应用程序的方法。
数据源控件也集成了缓存功能，并且打开和关闭默认缓存功能与设置Boolean属性一样容易。缓存对于数据绑定控件而言是透明的，并且数据源控件会管理它的某些方面，如生成缓存密钥和过期策略（时间和密钥依赖时间戳）。其他设置由页面开发人员来决定，包括数据在缓存中的生存期。请注意，数据源控件可为每个独特的连接字符串、选择查询、参数和缓存设置组合维护单独的缓存。
还应该注意的一个方面是，某些数据源控件（尤其是SqlDataSource）支持数据缓存过期，即能够检测数据库更改并使当前缓存的数据过期。稍后,您将会看到，该功能要求基础SQL存储区提供特定的支持。
使用数据源控件而不是传统的可枚举对象显然有许多优点，下面让我们考察一下它的某些缺点。正如曾经提到的那样，在ASP.NET 2.0中，每个数据绑定控件都支持双重API以便进行数据绑定。这些API彼此几乎完全隔离，基本上没有共同点。乍看起来，似乎数据源控件支持无代码绑定，并且只需通过指向和单击操作就可以完成可视化编程。勿庸置疑，您无需编写任何代码就可以创建数据驱动的页面。但是，这并不意味着数据绑定控件不允许您挂钩内部事件。新的体系结构具有更高的自动化程度，但它保留了ASP.NET 1.x中使用的显式数据绑定模型的所有方面。
总而言之，这两种模型之间的主要区别在于：当执行数据访问时，数据源控件将充当代理。如果活动的数据源对象对于您的应用程序至关重要，请考虑为每个受支持的数据操作激发一对操作前和操作后事件（如Deleting/Deleted事件）。这会给予您与ASP.NET 1.x中完全相同的数据流控制权，但这次是通过简单得多且更为紧凑的语法实现的。
最后，请记住数据源控件只是一组类。因此，您可以对它们进行完全的控制，并以编程方式实例化和操纵它们。这样做的时候，您将数据源控件用作在原始 ADO.NET类之上工作的更为抽象的API。在某种程度上，数据源控件代表着Data Application块的发展，后者是为.NET Framework 1.x引入的API，目的是实现常见的ADO.NET最佳做法，并且减少您需要编写的代码。
【编辑推荐】
