Infragistics Article

WebDataGrid DataViewState vs ViewState

Quick Summary

  • DataViewState stores only the row collection information (off by default)
  • ViewState stores “everything else”

Introduction

ASP.NET view state is a touchy subject. In recent years the entire concept of view state has been under scrutiny for it’s seemingly easy and endless abuse. But just as the baby should not be thrown out with the bath water, a mishandled tool does not render it useless.

Proper use of view state in ASP.NET pages can help performance (yes, I said help) and provide a number of other workflow and productivity benefits. This article’s aim is to dissect the differences between the WebDataGrid’s two view state properties: EnableDataViewState and EnableViewState.

Note: Before proceeding any further I strongly suggest that you read Dave Reed’s exceptional treatise on ASP.NET view state, TRULY Understanding ViewState as well as Scott Mitchell’s Understanding ASP.NET View State. These articles will set the foundation required to gain the proper perspective on how the grid’s view state flags work.

DataViewState

The concept of “data view state” was born from the Infragistics engineers’ desire to see view state handled correctly in the control. Traditionally ASP.NET controls place the values of nearly all properties into view state. Rather than stuffing all the grid’s data into HTML and ViewState, the WebDataGrid separates containers for data and any other of the grid’s properties. Therefore the only information placed in the DataViewState bag is the grid’s row collection. By default EnableDataViewState is set to false to ensure that data is included into view state upon explicit request.

Note: If you have DataViewState enabled along with the Paging behavior, only the current page’s row collection is tracked in the view state container.

EnableDataViewState

ViewState

 

While the WebDataGrid’s ViewState bag does not hold row collection information, it does keep track of style settings (CSS) and meta-data about the rows. Therefore if a user makes a customization to a row – the change in the row’s settings is maintained in ViewState even if the data itself is not persisted in the DataViewState bag. Taking this approach greatly reduces the view state maintained on a page.

By default the EnableViewState property is set to true.

EnableViewState

Recent Comments

By: ContInt Posted on 11-19-2011 5:04 PM

Hey - here's an idea - maybe post some samples of Using the Property with, say, dynamically changing DataSources (DataSets, Services), and how the separation of ViewState objects into an array element(yes, I looked at the source code)is really helping with providing a better experience ?

By: Louis315 Posted on 04-18-2011 5:24 AM

How does this relate to various values for EnableAjaxViewState and AutoCrud?  What about binding data with the DataSourceID property vs. the DataSource property?  The author has a note above to describe a special case for the paging behavior, but what about virtual scrolling?  How does setting EnableDataViewState = False "ensure that data is included into view state upon explicit request?"  Should that sentence say "ONLY upon explicit request" instead?

By: Louis315 Posted on 04-18-2011 5:13 AM

Why post a comment?  They are not answered.

By: wrlucas Posted on 03-24-2011 11:33 AM

Why post a comment?  They are not answered.

By: wdanda Posted on 08-18-2010 7:43 PM

Thanks for the post, quite informative.  So, when I'm using DataViewState, so I still need to reload (usually from the session) my grid's datasource for every post back (as its shown in many of the samples). Will it still keep the data that the user edited if I just use this DataViewState flag?

Thanks!

Wagner Danda da Silva

http://www.wagnerdanda.me

Sign in to post a comment to this article.