ASP.NET 2.0数据绑定机制
要在 ASP.NET 2.0 中生成新的数据绑定控件，首先需要确定哪个类能够更好地适合您的要求。然而，您的选择并不局限于比较空的类，如 Control 和 WebControl 甚至 ListControl。让我们探索一下那些深藏于幕后的类。BaseDataBoundControl 是所有数据绑定控件类的根。它定义了 DataSource 和 DataSourceID 属性，并且验证它们被分配的内容。DataSource 接受按照 ASP.NET 1.x 的方式获得和分配的可枚举对象。
- Mycontrol1.DataSource = dataSet;
- Mycontrol1.DataBind();
DataSourceID 是一个字符串，并且是指绑定数据源组件的 ID。一旦将控件绑定到数据源，则二者之间的任何进一步的交互（无论是读还是写）都将脱离您的控制范围，并且不可见。这一点既有好的一面，也有坏的一面。好（更确切地说是伟大）的一面在于可以消除大量代码。ASP.NET 框架能够保证正确的代码得以执行，并且按照公认的最佳做法编写代码。您的工作效率会更高，因为您可以完全确信在工作过程中不会出现令人难以捉摸的错误，从而可以更快地创作页。如果您不喜欢这种情况（好像很多 ASP.NET 1.x 开发人员都抱怨这种情况），则您可以继续使用通过 DataSource 属性和 DataBind 方法完成的旧样式的编程。而且，在这种情况下，基类使您不必完成一些常见的工作，即使这种效果在代码中体现得不是那么明显。
DataBoundControl 类用于与现有控件没有多少共同点的标准的自定义数据绑定控件。如果您必须处理自己的数据项集合，管理视图状态和样式，创建简单但量身定制的用户界面，则该类可以提供一个良好的起点。最为有趣的是，DataBoundControl 类将控件连接到数据源组件，并且在 API 级别隐藏了可枚举数据源和特别组件之间的任何差异。简而言之，当您从该类继承时，您只需要重写一个接收数据集合（无论数据源是 DataSet 对象还是较新的数据源组件）的方法。
让我们详细阐述这一点（它代表体系结构中的重大更改）。
BaseDataBoundControl 重写了 DataBind 方法（原来在 Control 上定义），并且使它调用 PerformSelect 方法（该方法被标记为受保护的和抽象的）。正如其名称所暗示的那样，PerformSelect 能够检索有效的数据集合以使绑定发生。该方法是受保护的，因为它包含实现细节；它是抽象的（用 Visual Basic 行话说就是 MustInherit），因为它的行为只能由派生类（如 DataBoundControl）确定。
那么，DataBoundControl 完成哪些工作以重写 PerformSelect 呢？
它连接到数据源对象并获得默认视图。数据源对象（例如，像 SqlDataSource 或 ObjectDataSource 之类的控件）执行它的选择命令并返回得到的集合。操作数据检索的受保护方法（名为 GetData）还足够聪明，以便检查 DataSource 属性。如果 DataSource 非空，则将绑定对象包装到一个动态创建的数据源视图对象中，并且将其返回。
ASP.NET 2.0数据绑定机制：下一个步骤
下一个步骤需要您以控件开发人员的身份参与。迄今为止，基类已经以一种完全自动的方式从 ADO.NET 对象或数据源组件中检索数据。下一个步骤取决于您期望该控件完成哪些任务。这里正好用到可重写的 PerformDataBinding 方法。以下代码片段显示了 DataBoundControl 中对该方法的实现。请注意，由框架传递给该方法的 IEnumerable 参数只包含要绑定的数据（不管它们的来源如何）。
- protected virtual void PerformDataBinding(IEnumerable data)
- {
- }
在自定义数据绑定控件中，您只需要重写该方法，并且填充任何特定于控件的集合，如包含很多个列表控件的 Items 集合（例如，CheckBoxList）。控件的用户界面的呈现发生在 Render 方法或 CreateChildControls 中，具体取决于该控件的性质。Render 适用于列表控件；而 CreateChildControls 则非常适合于复合控件。
有一件事情尚未解释：由谁启动数据绑定过程？在 ASP.NET 1.x 中，数据绑定需要显式调用 DataBind 方法才能开始工作。在 ASP.NET 2.0 中，如果您使用 DataSource 属性将数据绑定到控件，则仍然需要这样做。如果您改而通过 DataSourceID 属性使用数据源组件，则应当避免这样做。数据绑定过程由 DataBoundControl 中定义的内部 OnLoad 事件处理程序自动触发，如下面的伪代码所示。
- protected override void OnLoad(EventArgs e)
- {
- this.ConnectToDataSourceView();
- if (!Page.IsPostBack)
- base.RequiresDataBinding = true;
- base.OnLoad(e);
- }
每当该控件被加载到页中的时候（回发或首次加载），都会检索和绑定数据。需要由数据源决定是再次运行查询还是使用一些缓存数据。
如果该页是首次显示，则还会启用 RequiresDataBinding 属性以要求绑定数据。当分配的值为 true 时，该属性的设置程序会在内部调用 DataBind。下面的伪代码显示了 RequiresDataBinding 设置程序的内部实现。
- protected void set_RequiresDataBinding(bool value)
- {
- if (value && (DataSourceID.Length > 0))
- DataBind();
- else
- _requiresDataBinding = value;
- }
正如您可以看到的那样，为了向后兼容，仅当 DataSourceID 不为空（即您绑定到 ASP.NET 2.0 数据源控件）时，才会发生对 DataBind 的自动调用。有鉴于此，如果您还显式调用 DataBind，则会导致双重数据绑定。
请注意，您无法同时设置 DataSource 和 DataSourceID。当发生这种情况时，将引发无效操作异常。
最后，稍微提一下 EnsureDataBound 这一受保护的方法。该方法是在 BaseDataBoundControl 类上定义的，它能够确保控件已经被正确地绑定到必需的数据。如果 RequiresDataBinding 为 true，则该方法调用 DataBind，如下面的代码片段所示。
- protected void EnsureDataBound()
- {
- if (RequiresDataBinding && (DataSourceID.Length > 0))
- DataBind();
- }
如果您已经编写了复杂且完善的数据绑定控件，则您很可能已经知道我的意思。在 ASP.NET 1.x 中，在下列两种情况下，通常会将数据绑定控件设计为生成它自己的用户界面：该控件具有对数据源的完全访问权限，或者该控件基于视图状态。当该控件需要管理它自己的回发事件时（例如，假设该控件是支持分页的 DataGrid），则前面提到的两个选择似乎是两种极端的情况。在 ASP.NET 1.x 中，这些控件（同样，请考虑 DataGrid）只有一种解决办法：向要刷新的主页引发事件。该方法导致 ASP.NET 1.x 页中存在多余代码这一众所周知的问题 — 这也正是调用数据源组件来加以修复的问题。
在 ASP.NET 2.0 中，每当在控件的生存期中发生要求绑定数据的事情时，都需要将 RequiresDataBinding 设置为 true。设置该属性会触发相应的数据绑定机制，从而重新创建该控件的内部基础结构的更新版本。内置的 OnLoad 事件处理程序还会将该控件连接到数据源。为了确实有效，该技术必须依赖于能够将它们的数据缓存在某个位置的智能数据源控件。例如，SqlDataSource 控件支持很多属性，以便在给定期限内将任何绑定结果集存储到 ASP.NET 缓存中。
以上就介绍了ASP.NET 2.0数据绑定机制：如何生成新的数据绑定控件。
【编辑推荐】
