OnDataBinding vs Inline:优点,缺点和开销 [英] OnDataBinding vs Inline: pros, cons and overhead

查看:592
本文介绍了OnDataBinding vs Inline:优点,缺点和开销的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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



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



的内联ASP.NET代码示例:

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

我更喜欢做什么的例子:



在aspx中:

 < asp:Literal ID =litExamplerunat =server
OnDataBinding =litExample_DataBinding/>

在codebehind .cs:

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

我个人更喜欢codebehind方法,因为它保持我的aspx页面干净,没有所有的内联代码在所有的地方,下一个人只是知道总是看看.cs文件中的代码更改。



现在这些代码都是通过代码实现的,非常基本的例子。该字段可以是要用前导0格式化的整数,也可以是需要特定格式的DateTime。也可以采用所有类型的操作和代码来获取应该存储在文本属性中的终值



如果使用内联代码,在哪里绘制线条并将其移动到codebehind?



是否比另一个花费更多的开销?



编辑注意:我不是在为一个只在页面上的控件分配一个值,而是一个正在被数据绑定到的控件,因为它存在于转发器模板或gridview项目模板等。 ..显然坐在一个页面上你可以在代码中分配。



编辑注意:我想我会收集更多的回复,特别是关于开销。大多数人不使用OnDataBinding事件?

解决方案

它们之间几乎没有性能差异。数据绑定表达式被解析并编译成类似

  control.DataBinding + = new EventHandler(ControlDataBinding); 

以及

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

在这种情况下,OnDataBinding方法不会被覆盖。



当你重写OnDataBinding时,你只是接管了之前的基本代码运行,并自己设置 Text 属性。






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



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



您可以在磁盘上找到这些生成的代码文件。不记得在哪里。有趣的是,他们仍然工作,作为代码。



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



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


I thought I would ask this question to see why many examples and people prefer to use inline databinding in the aspx code vs implementing an OnDataBinding event when using WebForms.

For any databound control (eg. Repeater, GridView, etc) I always implement the OnDataBinding method for field level controls if I need to do anything that isn't built in out of the box (eg. I need to do an Eval). Most examples I see have the code right in the aspx page using the inline <%# syntax.

Example of inline ASP.NET code:

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

Example of how I prefer to do it:

In the aspx:

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

In the 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());
}

I personally prefer the codebehind method because it keeps my aspx pages clean and I don't have all this inline code all over the place and the next guy just knows to always look in the .cs files for code changes. The seperation of presentation and code is also maintained better this way as the HTML is place holders only and the codebind is determining what is actually being put in control.

Now these are very basic examples. The field could be a integer that you want to format with leading 0s or a DateTime that needs a specific format etc. It could also take all sort of manipulation and code to get the finally value that should be stored in the 'Text' property at the end.

Where do you draw the line and move it to the codebehind if you are using inline code?

What are the pros and cons for doing it either way?

Does one take more overhead than the other?

Edit Note: I am not talking about assigning a value to a control that is just on the page but one that is being databound to because it exists in a repeater template or gridview item template etc... Obviously a literal sitting on a page you can just assign in code.

Edit Note: I thought I would gather more response, especially with regards to the overhead. Do most people NOT use the OnDataBinding events?

解决方案

There's little performance difference between them. A data binding expression is parsed and compiles out to something like

control.DataBinding += new EventHandler(ControlDataBinding);

and also

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

In this case, the OnDataBinding method is not overridden. The base Control.OnDataBinding method is executed, which raises the DataBinding event, causing the above code to execute.

When you override OnDataBinding, you're simply taking over before the base code is run, and get to set the Text property yourself (for example).


I dislike giving out partial answers, but I'll do it this time because I think it's neat, and it saved me recently:

I said that the data binding expression are parsed. In fact, all of the markup is parsed, code in C#, VB.NET or whatever language is generated, and this is them compiled into a class. When the page is requested, an instance of this class is created, and it begins its life.

You can locate these generated code files on disk sorry, I don't remember where. The interesting thing about them is that they still work, as code.

For instance, I recently had some fairly complex Infragistics grids set up, had all the formatting complete, and then found that I needed to be able to set the formatting at rumtime (to get the correct format into exported Excel files). In order to do this, I opened the source file (all grids were in a single user control) and was able to extract the configuration of each grid into a separate group of methods.

I was able to clean them up with ReSharper, extract common code sequences into a base class, and was left with one static method to set up each grid. I was then able to call them both for the initial setup, and for the setup of the dummy grid used for Excel export.

这篇关于OnDataBinding vs Inline:优点,缺点和开销的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆