ObjectDataSource的问题

当我们不使用数据源控件的时候，通常是把查询和DataBind的方法写到!IsPostBack中。
但是当使用数据源控件的时候，如ObjectDataSource绑定到GridView上的时候，当点击GridView的编辑，选择甚至取消时，都会激发Select方法，重新查询数据库，这样是不是效率很低啊？有什么好的办法呢？让ObjectDataSource智能一些，比如当数据集并没有发生任何变化的时候，或者没有显性调用重新查询的时候，不要再次去查询，以免影响效率。

解决方案 »

  1.   

    这和传统的DataBind没什么太大的效率差别!!
    如果你点了编辑,这个编辑是回发的话,
    用ObjectDataSource不需要你编什么代码,就重新绑定了!
    而传统的需要编写代码来重新绑定!!
    这两者都要回发服务器,原理是一样的!!
      

  2.   

    ObjectDataSource我用下来,效率和传统的效率没有太明显的区别!!
    至于楼主所说的:
    "比如当数据集并没有发生任何变化的时候，或者没有显性调用重新查询的时候，不要再次去查询，以免影响效率。"
    我没觉得有这方面的问题!!
    如果你触发的是回发事件,则无论是用ObjectDataSource还是不用ObjectDataSource,原理是一样的!! 
    如果你用js处理,不回发的事件,则无论是用ObjectDataSource还是不用ObjectDataSource,也是一样的!! 
    楼主可否举个例子,来说明你的情况!!
      

  3.   

    一般来说不考虑这种原因引发的效率问题，如果你每次回发都会引起大数据量的查询，我想你就要考虑是否需要分页了。
    记得曾经也考虑过这个，用模版列+JS实现，只有在点击更新按钮的时候，会触发回发。点击编辑，让编辑按钮隐藏，更新和取消显示；点击取消，让更新和取消隐藏，编辑显示；点击更新执行UpdateCommand。不过个人感觉没有这种必要。这样考虑优化的话，那从某种概念上来说就不是服务端控件了，完全可以使用第三方的onclient控件，体验更好。
      

  4.   

    调用ObjectDataSource的Select方法，和查询数据库，这是隔着十万八千里的两回事。既然你选择了用ObjectDataSource，你给它的就是Object，例如ORM工具生成的Entity。你至少不会塞一个DataReader给ObjectDataSource吧。这时候，Entity自身如何去查询数据，是ObjectDataSource管不了的事情，ObjectDataSource只管去问Entity要数据。你真正应该关心的，是Entity的性能，但大多数成熟的ORM工具都能很好地利用缓存和延迟加载处理这个问题（假设你正确配置的话），所以这不应该是什么问题。