自定义 ASP.NET 控件如何在不使用 ViewState 的情况下缓存数据？
我不确定这在 ASP.NET 中是否可行，但这是我遇到的问题：我的 Web 应用程序上的一些数据列表是使用 GridView; 但是，由于其中一些列表可能包含大量数据，由于 ViewState。 由于我们不想每次在页面上有回发时都重新查询数据库以获取此信息，因此我想知道是否有一种方法可以缓存提供给服务器上的控件的数据，然后在下次访问它有一个回发。
那么这可能吗？ 如果是这样，有人可以向我指出有关如何执行此操作的更多信息吗？ 如果不可能，有人对我如何解决这个问题有任何建议吗？
I'm not sure if this is possible in ASP.NET, but here is the problem I have: some of the data lists on my web application are displayed using a GridView; however, because some of these lists can contain a lot of data, they sometime push the page weight up into the several megabyte range due to the ViewState. Since we don't want to requery the database for this information each time there is a postback on the page I was wondering if there was a way that I could cache the data given to the control on the server and then access it the next time there is a postback.
So is this even possible? If so can someone point me in the direction of more information on how to do this? If it is not possible, does anyone have any suggestions on how I might be able to solve this problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
除了页面之外，您还可以为视图状态使用不同的存储。 本文介绍了一些实现此目的的方法。
其要点是重写 SavePageStateToPersistenceMedium 和 LoadPageStateFromPersistenceMedium。
You can use a different store for your viewstate besides the page. This Article describes some methods for doing that.
The gist of this is to override SavePageStateToPersistenceMedium and LoadPageStateFromPersistenceMedium.
您可以尝试关闭 GridView 上的 ViewState。 这通常可以在不影响功能的情况下完成。 如果您的 GridView 仅显示数据且不允许编辑、更新、删除等，则效果非常好。
http://www.pluralsight.com/main/screencasts/screencast.aspx?id=understanding-viewstate
一般来说，您必须在客户端上的 ViewState 之间创建平衡以及服务器上某种类型的缓存。 不要非常害怕重新查询数据库。 它可以很好地缓存数据。 可能会考虑启用页面缓存。 我会避免将所有数据填充到 Session 中，这会带来一系列问题。
http://msdn.microsoft.com/en-us/library/hdxfb6cy。 ASPX
You might try turning off ViewState on the GridView. This can frequently be done without affecting functionality. Works very well if your GridView is only displaying data and doesn't allow edits, updates, deletes, etc.
http://www.pluralsight.com/main/screencasts/screencast.aspx?id=understanding-viewstate
In general, you have to create a balance between ViewState on the client and some type of cache on the server. Don't be horribly afraid of re-querying your database. It can cache the data quite well. Possibly look at enabling page caching. I would avoid stuffing all that data into Session which comes with its own set of problems.
http://msdn.microsoft.com/en-us/library/hdxfb6cy.aspx
以下是如何将 Viewstate 存储在本地临时文件中的示例：
http://www.marklio.com/ marklio/PermaLink.aspx?guid=af76f1a0-2d44-44c3-bfb5-029740b8e683
您仍然通过这种方法使用 Viewstate，但您不是填充 HTML，而是在服务器端创建临时文件。 因此用户不会注意到 Viewstate 很大。 您还可以重写上面的示例，将 Viewstate 数据存储在其他地方，例如数据库，甚至内存中。
这种方法的优点是您不必重写太多代码。 缺点是这些临时文件会填满服务器上的空间，需要偶尔清理一次。
Here is an example of how you can store the Viewstate in local temp files:
http://www.marklio.com/marklio/PermaLink.aspx?guid=af76f1a0-2d44-44c3-bfb5-029740b8e683
You are still using Viewstate with this approach, but instead of filling up the HTML you are creating temp files on the server side. Thus the user won't notice that the Viewstate is huge. You could also rewrite the sample above to store the Viewstate data somewhere else, like a database or even in memory.
The advantage of this approach is that you won't have to rewrite much code. The disadvantage is that those temp files will be filling up space on the server and needs to be cleaned up once in a while.
Rob，在你的情况下，我会尝试在会话中缓存从数据库检索的数据 - 网格第一次请求它时。
如果您尝试此操作并将其与禁用网格视图状态结合起来，您可以想出非常巧妙的解决方案。
如果您不能依靠 Session 进行缓存，那么总有一些替代的持久性机制可以完成这项工作。
但从给定情况的设计方面来看，我肯定会采用数据缓存方法。
Rob, what i would try in your case is to cache the data retrieved from the database in session - the first time grid is requesting it.
If you try this and combine it with the disabling of the view state for the grid, you can come up with pretty slick solution.
If you cannot count on Session for the caching, there are always some alternative persistence mechanisms that might do the job.
But from the design aspect of the given situation, i would definitely go with the data caching approach.