Last week I wrote an article "Where is the value of the control ViewState property saved?" It explained that Control.ViewState is ultimately accessed through the two methods Control.SaveViewState and Control.LoadViewState. There is a sentence in the article that may make you confused: "When we use this.ViewState[key] to read and write after OnInit, this property is true", where "this property" refers to StateItem.IsDirty. Why is the IsDirty property always true after OnInit? After referring to TRULY Understanding ViewState, I finally understood that it is not always true. Please listen to me explain the detailed reasons.
The first thing you need to look at is the StateBag.TrackViewState method. This method will be called when the control OnInit. Its function is to let StateBag start tracking changes in StateItem. Any changes will cause the IsDirty property of the StateItem to become true. . That is, before OnInit, the IsDirty property is false, and no matter how you set the value of the Value property, the IsDirty property will not be changed. After OnInit, the IsDirty property also remains false until you change the value of the Value property for the first time (referring to the change through the this.ViewState[key] method). At the SaveViewState stage, only StateItems whose IsDirty attribute is true will be saved.
Why is it designed this way? For example, a Label's Text property defined declaratively is assigned an initial value in ASPX, and then the initial value is naturally persisted through ViewState["Text"]. In the next page life cycle, first the Text property of this Label will load the initial value declaratively defined in ASPX during OnInit, and then overwrite it with ViewState["Text"] read from ViewState during LoadViewState. However, unless you programmatically changed the Text property in the previous page lifecycle, ViewState["Text"] is still the initial value, so you use ViewState["Text"] to save the initial value to overwrite the declaratively defined initial value. , it is completely meaningless to overwrite the same value in this way, and it also wastes ViewState space. In order to solve this problem of resource waste, any value that has not been changed after declarative definition should not be persisted using ViewState, and the detailed implementation is the TrackViewState mechanism mentioned above.
Speaking of which, Control.ViewState has been explained. If you are a control designer, you can safely store control properties in ViewState in the following ways:
public string Text
{
get {return this.ViewState["Text"] as string;}
set {this.ViewState["Text"] = value;}
}
Its internal mechanism will know how to distinguish whether the value you save is the initial value declaratively defined on ASPX, and then decide whether to persist the value. At the same time, if you want to change the determination of whether a ViewState value is persistent at any stage, you can change it through ViewState.SetItemDirty(key, dirty), which basically meets the needs of all control developers.
http://www.cnblogs.com/cathsfz/archive/2006/10/29/543695.html