代码之家 › 专栏 › 技术社区 › Jamie

以编程方式与对象数据源绑定以提高性能

database-performance data-binding performance asp.net

2

Jamie · 技术社区 · 15 年前

我用了包扎 GridViews , DetailViews 在我的页面上使用 ObjectDataSource (除非不可能这样做)。最近,我开始按程序绑定所有控件。我觉得这样更干净更容易,尽管有些人可能不同意。

与 数据源控件 很明显,它有优点和缺点,就像编程一样。

假设我以编程方式绑定GridView(例如。 GridView1.DataSource = SomeList ),当我在GridView上更改页面时,还必须对其进行编码。每次页面更改时,我都必须调用 GridView1.DataSource=一些列表 再一次。显然是因为 数据源控件 我不需要这么做。我通常坚持我的 SomeList 对象进入ViewState,因此当我更改页面时,不需要每次都访问数据库。

我的问题是:ObjectDataSource就是这样工作的吗?它是否将其数据存储在ViewState中,并且除非调用 .Select 方法?我喜欢尝试从应用程序中获得最好的性能,并尽可能少地访问数据库,但我不太喜欢在ViewState中存储一个大列表的想法。有更好的办法吗?为每个用户缓存是一个好主意(还是可能)?我应该每次都点击数据库而不是将我的大列表存储在ViewState中吗?有时命中数据库比使用ViewState更好吗?

1 回复 | 直到 15 年前

1

Aristos 15 年前

它是否将其数据存储在ViewState中,并且除非调用.Select方法,否则不会再次命中数据库?

不,它不在ViewState中保存数据 . 在视图状态gridview和其他类似列表中,保存常规状态,例如排序列、页面、总页面、控件状态,但不保存数据。

为每个用户缓存是个好主意吗

缓存 每个用户 在服务器端不是很好,除非缓存只持续几分钟或者/并且要缓存的数据非常小。如果你为每个用户缓存大量的数据很长一段时间,它们会增长得太快,特别是如果用户开始阅读大量的页面,那么最终你也会遇到同样的问题。

现在您必须显示来自多个表的关系的大量数据,那么最好将表的完整关系缓存到“一个平面表”。

我应该每次都点击数据库而不是将我的大列表存储在ViewState中吗?

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