OnDataBinding vs Inline:优点,缺点和开销

我想我会问这个问题,看看为什么很多例子和人们更喜欢在aspx代码中使用内联数据绑定而不是在使用WebForms时实现OnDataBinding事件.

对于任何数据绑定控件(例如,Repeater,GridView等),我总是为字段级控件实现OnDataBinding方法,如果我需要做任何不是开箱即用的东西(例如,我需要做一个Eval).我看到的大多数示例都使用内联<%#语法在aspx页面中使用了正确的代码.

内联ASP.NET代码示例:

我更喜欢这样做的例子:

在aspx中:

在codebehind .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只是占位符,而代码绑定正在确定实际控制的内容.

现在这些是非常基本的例子.该字段可以是您想要使用前导0格式化的整数,也可以是需要特定格式等的DateTime.它还可以采用所有类型的操作和代码来获取应存储在"Text"属性中的finally值.结束.

如果使用内联代码,在哪里绘制线并将其移动到代码隐藏？

这样做的优点和缺点是什么？

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

编辑注意:我不是在谈论为页面上的控件分配值,而是将数据库分配给,因为它存在于转发器模板或gridview项目模板等中...显然,文字坐在页面上可以只在代码中分配.

编辑注意:我想我会收集更多响应,特别是关于开销.大多数人不使用OnDataBinding事件吗？

我更喜欢相反的情况.我更喜欢将代码隐藏在程序代码中,并将所有声明代码保存在我的Aspx页面中.在上面的示例中,文字是绝对声明的,因此(根据我的偏好)不属于代码隐藏.更强大的功能通常出现在我的代码隐藏中,并且我不希望我的开发人员在尝试理解它时必须筛选一堆初始化行.

它们之间的性能差异很小.解析数据绑定表达式并编译成类似的东西

control.DataBinding += new EventHandler(ControlDataBinding);

并且

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

在这种情况下,不会覆盖OnDataBinding方法.执行基本Control.OnDataBinding方法,该方法引发DataBinding事件,导致上述代码执行.

当您重写OnDataBinding时,您只是在运行基本代码之前接管,并Text自己设置属性(例如).

我不喜欢给出部分答案,但这次我会这样做,因为我觉得它很整洁,最近救了我:

我说过解析了数据绑定表达式.事实上,所有的标记都被解析,代码用C#,VB.NET或者生成的任何语言,这就是它们被编译成一个类.当请求页面时,将创建此类的实例,并且它将从其生命开始.

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

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

我能够用ReSharper清理它们,将公共代码序列提取到基类中,并留下一个静态方法来设置每个网格.然后,我可以将它们称为初始设置,以及用于Excel导出的虚拟网格的设置.