以编程方式绑定。性能的对象数据源

Question

我使用GridViews在我的页面上使用绑定所有DetailViews，ObjectDataSource等（除非无法这样做）。最近，我开始以编程方式绑定我的所有控件。我发现这更清洁，更容易，但有些人可能不同意。

与ObjectDataSource绑定显然有其优点和缺点，就像以编程方式进行绑定一样。

假设我以编程方式绑定了一个GridView（例如GridView1.DataSource = SomeList），当我在GridView上更改页面时，我还要对此进行编码。每次页面更改时，我都必须再次调用GridView1.DataSource = SomeList。显然使用ObjectDataSource我不需要这样做。我通常会将SomeList对象粘贴到ViewState中，因此当我更改页面时，我不需要每次都访问数据库。

我的问题是：这是ObjectDataSource的工作原理吗？它是否将数据存储在ViewState中，除非您调用.Select方法，否则不会再次访问数据库？我喜欢尝试从我的应用程序中获得最佳性能并尽可能少地访问数据库但我不太喜欢在ViewState中存储大量列表的想法。有没有更好的方法呢？每个用户缓存是一个好主意（或可能）？我是不是每次都会点击数据库而不是将我的巨大列表存储在ViewState中？点击数据库有时比使用ViewState更好吗？

Answer 1

  

它是否将数据存储在ViewState中，除非您调用.Select方法，否则不会再次访问数据库？

不能保存ViewState中的数据。在视图状态gridview和其他类似列表中，保存常规状态，例如排序列，页面，总页数，控制状态，但不保存数据。

  

每位用户缓存是个好主意

服务器端的每用户缓存并不是一个好主意，除非缓存仅持续几分钟或/和您要缓存的数据非常小。如果长时间为每个用户缓存大量数据，如果用户开始阅读大量页面，那么这些数据会增长太多，最终会出现同样的问题。

现在你必须显示来自许多表的关系的大量数据，然后最好将表的完整关系缓存到“一个平面表”。

  

我每次只是点击数据库而不是将我的巨大列表存储在ViewState中吗？

这还取决于您设计数据读取的速度。对我来说最好保持ViewState较小，并且只保留在页面上执行操作所需的信息，而不是数据。