c# - OnDataBinding与内联: pros,缺点和开销

我想问一下这个问题，以了解为什么许多示例和人们更喜欢在aspx代码中使用内联数据绑定(bind)而不是在使用WebForms时实现OnDataBinding事件。

对于任何数据绑定(bind)控件(例如，Repeater，GridView等)，如果我需要执行非开箱即用的内置操作(例如，我需要执行Eval)，则始终为字段级控件实现OnDataBinding方法。 )。我看到的大多数示例都使用内联
内联ASP.NET代码示例:

<asp:Literal ID="litExample" runat="server"
    Text='<%# Eval("ExampleField").ToString() %>' />

我更喜欢这样做的示例:

在aspx中:

<asp:Literal ID="litExample" runat="server"
    OnDataBinding="litExample_DataBinding" />

在.cs背后的代码中:

protected void litExample_DataBinding(object sender, System.EventArgs e)
{
    Literal lit = (Literal)(sender);
    lit.Text = string.Format("{1} - {2}",
        Eval("ExampleField").ToString(),
        Eval("ExampleField2").ToString());
}

我个人更喜欢codebehind方法，因为它可以使我的aspx页面保持干净，而且我并没有到处都有这些内联代码，而下一个家伙只知道总是在.cs文件中查找代码更改。这样，由于HTML仅是占位符，并且代码绑定(bind)确定了实际要控制的内容，因此可以更好地保持表示和代码的分离。

现在，这些是非常基本的示例。该字段可以是您要以前导0格式化的整数，也可以是需要特定格式的DateTime等。它还可以进行各种操作和代码以获取最终值，该值应存储在以下位置的“文本”属性中:结束。

如果使用内联代码，您将在哪里画线并将其移动到后面的代码？

两种方式的优缺点分别是什么？

一个会比另一个花费更多的开销吗？

编辑注意:我不是在说给仅在页面上但正在被数据绑定(bind)的控件分配值，因为它存在于转发器模板或gridview项目模板等中。您可以只在代码中分配页面。

编辑说明:我想我会收集更多的响应，尤其是在开销方面。大多数人不使用OnDataBinding事件吗？

最佳答案

它们之间几乎没有性能差异。解析数据绑定(bind)表达式并将其编译为类似

control.DataBinding += new EventHandler(ControlDataBinding);

并且

private void ControlDataBinding(object sender, EventArgs e) {
    control.Text = Eval("Field");
}

在这种情况下，不会重写OnDataBinding方法。基本Control.OnDataBinding方法被执行，这将引发DataBinding事件，从而导致上述代码得以执行。

当覆盖OnDataBinding时，您只需要在运行基本代码之前接管工作，然后即可自行设置Text属性(例如)。

我不喜欢给出部分答案，但是这次我会这样做，因为我认为它很整洁，最近它为我省了很多钱:

我说过，数据绑定(bind)表达式已解析。实际上，所有标记都会被解析，使用C#，VB.NET或任何语言生成的代码，然后将它们编译成一个类。当请求页面时，将创建此类的实例，并开始其生命周期。

您可以在磁盘上找到这些生成的代码文件，抱歉，我不记得在哪里。关于它们的有趣之处在于它们仍然可以作为代码工作。

例如，我最近设置了一些相当复杂的Infragistics网格，完成了所有格式设置，然后发现我需要能够在rumtime设置格式(以将正确的格式导入导出的Excel文件中)。为此，我打开了源文件(所有网格都在单个用户控件中)，并且能够将每个网格的配置提取到单独的一组方法中。

我能够使用ReSharper清理它们，将常见的代码序列提取到基类中，然后剩下一个静态方法来设置每个网格。然后，我既可以为初始设置，也可以为用于Excel导出的虚拟网格的设置调用它们。