在asp.net的网页中往往看到这样的数据绑定:
<%#databinder.Eval(container.dataitem,"userid")%>
还有这样的
<%#container.dataitem("content")%>这里我不是很懂,对于数据绑定,上面两种什么意思,还有没有其他的写法啊,请高手解释下
<%#databinder.Eval(container.dataitem,"userid")%>
还有这样的
<%#container.dataitem("content")%>这里我不是很懂,对于数据绑定,上面两种什么意思,还有没有其他的写法啊,请高手解释下
解决方案 »
- 大家评评这篇文章所说的问题,是不是真的存在?--如此高效通用的分页存储过程是带有sql注入漏洞的
- vs2008 DataList RadioButtonList 控件绑定不了?在线等
- vs2005如何重新整合水晶报表控件
- Linq to sql怎么调用存储过程??
- 实现二次查询
- 64位系统带来的oracle连接问题
- Repeater中使用单选按钮的问题
- 求分页空间和详细的使用方法,谢谢
- DataGrid求助
- vs.net怎样打开一个aspx的文件有html编辑页面?
- 微软专家和高手们求救:使用OleDbCommandBuilder更新da.update(dt)oracle 9.12数据库操作失败。
- 开始学asp.net是用VB,现在用觉得企业招人都要会C#的,我决定转一下了。
<@% DataBinder.Eval(Container.DataItem, "ColumnName", null) %>
<@% DataBinder.Eval(Container, "DataItem.ColumnName", null) %>
<@% ((DataRowView)Container.DataItem)["ColumnName"] %>
<@% ((DataRowView)Container.DataItem).Row["ColumnName"] %>
NOTE: 后两种用法需要引入System.Data名称空间……乍一看1-3都是使用DataBinder.Eval方法来进行数据绑定计算,而4-5是使用strong type直接获取数据绑定的值。按照我之前的推理,很多朋友会认为4-5都会比1-3快,而实际上第4种用法也是在网上很常见的一种针对DataBinder.Eval而进行的“优化”。实际上根据我们的测试,第4种写法的效率在某些很常见的情形下(即传入的字段名与数据表内部的字段名大小写有出入时)甚至比不上最普遍的第1种写法。不过原理还是对的,就是避免通过reflection或类似机制(如System.ComponentModel中的PropertyDescriptor机制)获得数据,然而使用DataRowView的indexer的效率在字段数量较多导致Hashtable产生寻址冲突时不如使用其Row属性(DataRow类型)的indexer的效率。原因是DataRowView的indexer实现了view的功能,而这个功能对于大多数应用在这个场合都是不需要的,且它的开销甚至比DataBinder.Eval还要大!(本段内容过于武断,在被反复质疑之下我又做了若干试验寻得正确原因)因此简单的使用第五种写法通常是可以获得较佳的性能的,而最好不要在不必要的时候直接使用DataRowView的indexer。现在回到1-3的讨论。首先一点,请大家注意看Eval方法的二种overload:object DataBinder.Eval(object container, string expression)
string DataBinder.Eval(object container, string expression, string format)注意到ASP.NET在生成的.cs文件中是使用System.Convert.ToString来将Eval的结果转换成string的,因此显式的提供值为null或String.Empty的format参数将使得Eval首先调用第一种方法得到绑定结果的对象,然后直接调用该对象的ToString()方法将其返回到Convert.ToString方法,对于该方法编译器已经在编译期将其连接到Convert.ToString(string)的重载上,而该方法则直接返回传入的字串。那如果直接使用第一种方法呢?虽然第二种方法是先调用第一种方法的,但是由于它的返回值是object类型,编译器将为其选择Convert.ToString(object)的重载,在这个重载方法中将进行一些额外的判断以将对象转换为string类型,而这些额外判断显然带来了额外的开销——尽管基本上算不得主要矛盾。至于说第3种写法,由于在expression参数中多引入了一层间接,因此需要多进行一次反射以解析表达式,因此效率非常之低。那这里再卖个关子,请推测第5种方法是否还可以进一步优化?(我是指在最常见的ASP.NET开发情形中):P通过上面的分析,我们可以得到下面的结论:DataBinder.Eval是最常用也比较易用的数据绑定表达式写法,但由于其实现机制使用了反射,所以需要关注其所带来的性能损失。通常,当应用开发进入稳定期后可以针对性的对这些表达式进行优化。
但是优化不是光从字面上就能感觉到的,第4种所谓优化随处可见,然而在某些情况下它反而带来其他环节的开销,带来比较低的执行效率。
要注意方法重载是一种编译期机制,通过显式告诉编译器需要使用的方法重载,通常可以在得到同样结果的前提下获得更佳的性能。
性能虽重要,功能价更高——在一般的项目开发中,还是首先关注功能的实现,然后再通过实际测试有针对性的优化比较突出的性能瓶颈。
希望我的这点儿心得对您有所启发。:)