RE: ViewState vs. Database
- From: MCM <MCM@xxxxxxxxxxxxxxxx>
- Date: Wed, 9 Jul 2008 23:15:00 -0700
From your description, you're wondering tradeoff between storeing database
records in ASP.NET page's viewstate and query them in every request,
correct?
Yes.
Based on my understanding, if you're using Databound control(such as
Gridview, DataGrid)
Not using datagrid. Using custom display controls. I can choose to
enable/disable viewstate.
3. If the bottleneck is not at the web application and backend database
server(performing data accessing operations such as query data), I
recommend you query the data from database in every request where you need
to display the data. But if the data is large and really static or
unchangable, you can consider using Application Cache to cache them.
That is my point. I don't know where my bottleneck is yet. I'm looking for a
"best practice". Something that works in most scenarios. I can choose to
enable view state and only hit the database once - then reuse the data for
multiple postbacks - this will obviously create a larger html response to the
client. Or I can choose to keep the page size smaller, but hit my database on
each postback - this will be more taxing on the server of course. As a
general rule - which is better? And why?
-------------------
#Using the ASP.NET Application Cache to Make Your Applications Scream.
http://www.developer.com/net/net/article.php/1477771
#ASP.NET Caching Overview
http://msdn.microsoft.com/en-us/library/ms178597.aspx
Sincerely,
Steven Cheng
Microsoft MSDN Online Support Lead
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msdnmg@xxxxxxxxxxxxxx
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
Thread-Topic: ViewState vs. Database
thread-index: AcjiL9LHoL7fpWJYTuakWT7C3nnrKw==
X-WBNR-Posting-Host: 207.46.19.168
From: =?Utf-8?B?TUNN?= <MCM@xxxxxxxxxxxxxxxx>
Subject: ViewState vs. Database
Date: Wed, 9 Jul 2008 18:54:00 -0700
I
I'm sure the answer to my question varies depending on the situation, but
am looking for a general "best practice".
If I have an asp.net application and I load certain data from a database,
should I use ViewState to store and reload the data, or should I load the
data from the database on each postback?
Assume for the sake of this question that I only care about performance, I
don't care about ease of programming.
- Follow-Ups:
- RE: ViewState vs. Database
- From: Steven Cheng [MSFT]
- RE: ViewState vs. Database
- References:
- RE: ViewState vs. Database
- From: Steven Cheng [MSFT]
- RE: ViewState vs. Database
- Prev by Date: RE: Where are the managed newsgroups for the .Net 3.5 technologies?
- Next by Date: ASP.NET ajax client side framework failed to load
- Previous by thread: RE: ViewState vs. Database
- Next by thread: RE: ViewState vs. Database
- Index(es):
Relevant Pages
|