GridView的分页是否真的是鸡肋呢?

    现在大家一直都公认GridView的分页算法效率特别低,大家都是采用按需所取,只取当前页的数据,并不把所有记录全部取出来.在数据量大的情况下,此种方案无疑是最优的.但是有的时候有可能没有办法这样办到,比如:


        1: 数据集需要跨远程数据库.


        2 :数据集的返回方式可能是web service或者是.net remoting,wcf等分布式形式.

        3 :返回的数据库会发生多次的排序操作.

   
    针对某些情况,我们应该实际情况实际分析.


        1:结果集以远程web service返回,分布式调用性能略抵,频繁的调用并不理想.


        2:数据集需要跨数据库.有时数据需要整合两个以上的数据库的数据,这对按需所取造成一定的困难.


        3:数据量特别大,所以只允许杳前n条记录,例如前3000条.这种最终查询数据量不大的情况下,全部取出所付的代价并不大.


        4:对结果集会有多种排序操作.如果不一次性全部取出来,那么每一次排序你都要重新调用数据库,这样并不完美.

     
      解决方案: 所以我觉的上面的情况并不适合按需所取,就算全取出来也不过3000条,对于web service来说也是完成没问题的.如果些时把结果集缓存起来,第二次绑定的时候就不用调用数据库而直接调用缓存,这样效率上会非常高.


    当 GridView 控件移动到新的数据页时,该控件会引发两个事件。PageIndexChanging 事件在 GridView 控件执行分页操作之前发生。PageIndexChanged 事件在新的数据页返回到 GridView 控件之后发生。引自MSDN,也就是说分页事件发生后会重新绑定数据集.即点击任何一页都要把所有的数据全部取出来,这样在性能上的代价当然是相当高,而且的时是无法忍受的.


   本人在本地测试中,构造了一个具有12列100000行的DataTable,然后绑定在GridView,然后将 GridView 控件的 AllowPaging 属性设置为 true,在PageIndexChanging事件中写入如下代码:

/// <summary>
        
/// 分页事件
        
/// </summary>
        
/// <param name="sender"></param>
        
/// <param name="e"></param>
        protected void GridView1_PageIndexChanging(object sender, GridViewPageEventArgs e)
        {
            
//将新的索引值赋值给GridView
            this.GridView1.PageIndex  = e.NewPageIndex;
            
//重新绑定数据
            display();
        }

     相关的方法如下(没有启用缓存):

Code

      此时点击任何一页的数据,加载的时间都是3S以上,不过当我作用缓存后时间都是1S以下.

      使用缓存的方法如下:


 

Code

      下面是两张没有用缓存的用时情况:


      

     下面是两张使用缓存后的用时情况:

        总结:凡是一个产品的存在总会有它存在的道理,所有我们应该实际情况实际分析,不能千篇一律,只要用心总能找出适用自己的方法.是否是鸡肋,不在事物本身,而在于看待事物的人,不同的眼光会看出不同的风采.

注:

    本文引用:MSDN

原文地址:https://www.cnblogs.com/ASPNET2008/p/1306699.html