Thoughts on grids and viewstate

Published 21 July 05 09:59 AM | despos

Fritz raises an interesting point about grids and viewstate. I replied suggesting that simply resetting the DataSourceID property (to the same value) triggers a process that in the end fixes the issue. Sure, it's kind of hacky, but it works.

However, I coundn't agree more with Fritz that 1) disabled viewstate on the grid; 2) caching through the data source control are overall the best approach to displaying data through grids without killing the page--in download, but also in upload.

I thought I should share a few additional remarks on the topic here.

Caching is fine, especially now that it is kind of "free". You just set EnableCaching and go. Note that, for some reasons, caching is not enabled (Beta 2, at least) on ObjectDataSource when you use custom collections. In this case, caching should be implemented in the bound objects--your BLL.

  • Easy and blissful caching might lead to sub-optimal code if this means that you let the page cache everything results from a query. Keep the size of the data in the cache under control.
  • Back to viewstate and grids, note that the size of the viewstate that results from a grid (both DataGrid and GridView) mostly depends on styles and additional helper properties being saved. Control state is not the point here, as it is saved to the viewstate hidden field anyway. It differs from classic viewstate because of the different API and because it can't be disabled. 
  • True data in the viewstate for a grid is not really much--just the displayed strings.

While disabling the viewstate is definitely a good option keeping everything else that is critical to the control to the control state, I'd spend some thoughts on the fact that style properties take up most of the viewstate and they're 90% of the time constant and written to the .aspx when not in a theme. Why persisting to the viewstate? With this info in the viewstate, the grid can rebuild itself with no data access when in the IsPostBack branch. This makes sense if you want to save a roundtrip to the database, but not if you have data cached.

 

Comments

# Brock Allen said on July 21, 2005 11:00 AM:

[quote]Fritz raises an interesting point about grids and viewstate. I replied suggesting that simply resetting the DataSourceID property (to the same value) triggers a process that in the end fixes the issue. Sure, it's kind of hacky, but it works.[/quote]

Just calling DataBind is more straightforward, don't you think?

# DinoE said on July 21, 2005 11:10 AM:

Hi Brock,
I confess that without trying it, I deduced it wouldn't have worked. Thus I went straight on to the DataSourceID trick. Of course, you're right.

Being bound to a data source control makes me thinking of NOT using DataBind; no questions if you're bound to a classic data source object.

Functionally, it's the same.

# Daniel said on July 28, 2005 07:25 PM:

I wrote my own pager control for repeater/grid/list in beta 2 whidbey because I got really tired of big download times from large result sets being shot to the browser every time a filter was applied, or a whatever... So to accomplish this I pass my dataset into my pager control and have variables in the control for like page size and current page. I then have the pager control parse the records and create a new dataset then pass it back to the grid/list/repeater and bind. This is working MUCH better for me as I don't try to pass 1000 rows of data to the client and the dataset parsing seems fairly fast on the server side.

I do realize that with beta 2 you can use server side caching...but the only way to do that, from what I have found, is by using the datasource control...of which I am not to fond of because I dont like having queries/connections in the page code itself.

So when setting the data source on a grid/list/repeater i do something like this

grvGrid.DataSource = MyPagerControl(DS) ' DS being the dataset I already have populated.

grvGrid.DataBind() 'yada yada yada


Then MyPagerControl(DS) (a function in the control that returns a dataset) recieves the dataset, parses it, and returns only the records for the current page.


It might seem hackish...but it works for me...and allows me to have all my code in the code-behind instead of in a datasource control on the page.

If I am way off...or you guys know of a better solution...I'm open to hear it.

# Daniel said on July 28, 2005 07:27 PM:

Oops..in my previous post I made a mistake...

"I do realize that with beta 2 you can use server side caching"

was ment to read

"I do realize that with beta 2 you can use server side paging"


Daniel

Leave a Comment

(required) 
(required) 
(optional)
(required)