如果你开启GridView的删除功能,你会发现删除最后一页的最后一条记录时,GridView消失了,而不是正确的减掉PageIndex的值.在我们上面创建的GridView里开启删除来查看这个bug.到最后一页(第九页),由于我们有81条记录,每页显示10条,所以你会只看到一条记录,删除这条记录.
在默认分页时,GridView会自动跳到第八页,这也是我们想要的结果.然而在自定义分页里, GridView却显示.发生这个的原因有点超出了本教程的范围,可以看Deleting the Last Record on the Last Page from a GridView with Custom Paging.简单的说是因为点Delete时,GridView是按这样的步骤工作的:
删除记录.
按照给定的PageIndex和PageSize获取记录.
检查PageIndex确保没有超过数据源的页的数量.如果是,GridView的PageIndex会自动减.
使用第二步获取的记录绑定到GridView适当的页.
问题的根源在于第二步,当获取显示的记录时,使用的PageIndex仍然是最后一页的PageIndex.因此没有记录被返回.在第三步里GridView判断出PageIndex属性大于数据源的总页数(因为最后一页的最后一条数据被删除了) 就对PageIndex减1.在第四步里GridView试图将第二步获取的数据作为数据源进行绑定,但是没有任何数据,因此显示的GridView不见了.在默认分页里没有这个问题是因为在第二步还是返回的所有数据.
我们可以用两种方法来修改这个.第一是为GridView的RowDeleted事件创建一个event handler
来判断在删除页里有多少条记录,如果只有一条,那么这条肯定是最后一条,我们需要为PageIndex减1.当然我们希望只在删除成功后来修改PageIndex的值.我们需要用e.Exception属性是否为空来判断.
这个方法之所以起作用是因为它在第一步和第二步之间修改了PageIndex的值.因此在第二步里正确的记录会被返回.见如下代码:
protected void GridView1_RowDeleted(object sender, GridViewDeletedEventArgs e) { // If we just deleted the last row in the GridView, decrement the PageIndex if (e.Exception == null && GridView1.Rows.Count == 1) // we just deleted the last row GridView1.PageIndex = Math.Max(0, GridView1.PageIndex - 1); }
另外一种办法是为ObjectDataSource的RowDeleted事件创建一个event handler,设置AffectedRows属性为1.在第一步删除记录后(在第二步之前),如果一行或多行记录被影响,GridView会更新PageIndex的值.然而ObjectDataSource 并没有设置AffectedRows,因此这一步不会执行.我们需要在删除操作成功的情况下手动设置AffectedRows.见下面的代码:
protected void ObjectDataSource1_Deleted( object sender, ObjectDataSourceStatusEventArgs e) { // If we get back a Boolean value from the DeleteProduct method and it's true, // then we successfully deleted the product. Set AffectedRows to 1 if (e.ReturnValue is bool && ((bool)e.ReturnValue) == true) e.AffectedRows = 1; }
这些代码都可以在EfficientPaging.aspx的code-behind class里找到
比较默认和自定义分页的性能
由于自定义分页返回需要的数据,而默认分页返回全部数据,因此自定义分页比默认分页更有效率是非常清楚的.但是性能上的提升究竟有多少?从默认分页换成自定义分页有什么性能上的优势?
很不幸,没有一个统一的答案.性能的优势取决于很多因素,其中最重要的是分页记录的数量,数据库的负载和web server和数据库的通信渠道.对一些小的表来说,性能的差异是可以忽略的.对成千上万行数据的表来说,差异是非常明显的.
我们的一篇Custom Paging in ASP.NET 2.0 with SQL Server 2005文章包含一些对比这两种分页技术的性能测试,用到的表有大概50,000 条记录.在测试中我分别测试了在SQL Server里（使用SQL Profiler）和ASP.NET页面里（使用ASP.NET's tracing features）执行查询的时间．注意这是在我的开发环境下单个用户的测试结果，因此没有模仿典型的网站的负载情况，结果也并不科学．
Avg. Duration (sec)
Reads
Default Paging – SQL Profiler
1.411
383
Custom Paging – SQL Profiler
0.002
29
Default Paging – ASP.NET Trace
2.379
N/A
Custom Paging – ASP.NET Trace
0.029
N/A
如你所见，获取特定页的数据平均少了354 reads，并在恩短的时间完成．而在页面里，自定义分页是默认分页所花费时间的1/100．在my article 可以看到更多的测试信息和代码，你可以下载测试数据库在你的环境里重新测试．
总结