以编程方式绑定 vs. 以编程方式绑定用于提高性能的对象数据源

发布于 2024-10-02 07:17:35 字数 734 浏览 3 评论 0原文

我使用 ObjectDataSource 绑定页面上的所有 GridViewsDetailViews 等(除非不可能这样做)。最近,我开始以编程方式绑定所有控件。我发现这更干净、更容易,尽管有些人可能不同意。

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

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

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

I used bind all GridViews, DetailViews etc. on my page using an ObjectDataSource (unless it wasn't possible to do so). Recently, I've started binding all my contols programatically. I find this a lot cleaner and easier, though some may disagree.

Binding with a ObjectDataSource obviously has it advantages and disadvantages, as does doing it programatically.

Say I bind a GridView programatically (e.g. GridView1.DataSource = SomeList), when I change page on the GridView, I have to also code this. Each time the page changes I have to call GridView1.DataSource = SomeList again. Obviously with a ObjectDataSource I don't need to do this. I normally stick my SomeList object into the ViewState so when I change page I don't need to hit the database each and every time.

My question is: Is this how the ObjectDataSource works? Does it store it's data in the ViewState and not hit the database again unless you call the .Select method? I like to try and get the best performance out of my applications and hit the database as few times as possible but I don't really like the idea of storing a huge list in the ViewState. Is there a better way of doing this? Is caching per user a good idea (or possible)? Shall I just hit the database everytime instead of storing my huge list in the ViewState? Is it sometimes better to hit the database than to use ViewState?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

我家小可爱 2024-10-09 07:17:35

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

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

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

在服务器端对每个用户进行缓存并不是一个好主意,除非缓存仅持续几分钟或/和您要缓存的数据非常小。如果您长时间为每个用户缓存大量数据,那么它们会增长太多,特别是如果用户开始阅读大量页面,那么最终您会遇到同样的问题。

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

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

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

Does it store it's data in the ViewState and not hit the database again unless you call the .Select method?

No its not save the data in ViewState. In the view state gridview and other similar lists, saves the General Status, eg the sort column, the page, the total pages, the control state, but not the Data.

Is caching per user a good idea

The caching per user on server side is not so good idea except if the caching is last for few minutes only or/and the data that you going to cache is very small. If you cache per user large amount of data for long time they going to grow too much especial if a user starts to read a lot of pages, that at the end you have the same problem.

Now you have to show a large amount of data that come from the relation of many tables, then maybe is better to cache the full relation of the tables to "one flat table".

Shall I just hit the database everytime instead of storing my huge list in the ViewState?

This is also depend from how fast you have design the reading of your data. For me is better to keep the ViewState small, and keep there only informations that you need to make the actions on your page, and not data.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文