Asp.net viewstate Learning

These are the things that our predecessors have studied, and I just copied their results. Well, I will not talk about anything. Let's start with a table:

Page events	Viewstate related operations
Preinit	Set static properties of Controls
Init	Run the trackviewstate method (enable viewstate tracking)
Initcomplete
	Hide the field from _ viewstate to update the control property. Because most of the control properties are actually stored in viewstate, it can also be said that the viewstate is restored/updated, and Mark recovered/updated viewsate as dirty
	Update control attributes from the returned postdata Value
Preload
Load
	Update control properties from the returned postdataw value again
Loadcomplete
Presender
Presendercomplete
	Run the saveviewstate method (all viewstates marked as dirty are stored)
Sender
Unload

 

 

Let's talk about your experiences. Why do we care so much about viewstate and facilitate programming? This is only one of them. If we don't pay attention to it, viewstate may be applied to us.ProgramNegative impact. The most important thing is to "infinitely increase the page size ". In fact, many of them can be avoided!

In the viewstate lifecycle (which stage is the most noteworthy? I think it is the time to execute the trackviewstate method. When this method is executed, any changes to the control status will be recorded by viewstate in the future, which is also the source of the "infinite increase" page size.

What is the idea of viewstate? Yes, no changes can escape the viewstate eyes!

If we want to compile a work with excellent performance, we will not miss the optimization of viewstate, especially for those static data, they only play a role in display and will not be modified. Therefore, for the above two features, we have two solutions: either not using viewstate, or changing the value before the trackviewstate method is executed.

Before programming the page, we need to perform an analysis on the page, which data is only for display static data, and which data is dynamic data that requires users to complete interaction. All we need to do is let the viewstate record the interaction states.

Of course, the above is too idealistic, but it is one of our principles of Asp.net, and we can do our best to lean on it.

After reading a number, the viewstate should not exceed 30% on the page or be less than 30 kb. Otherwise, the performance is generally not good. Although I am not familiar with this number, but trying to narrow down the viewstate is the unshirkable responsibility of every Asp.net programmer!

 

ReferenceArticle:

1. More in-depth understanding of viewstates (1)

Http://blog.csdn.net/orichisonic/archive/2008/10/15/3078994.aspx

2. More in-depth understanding of viewstates (2)

Http://blog.csdn.net/orichisonic/archive/2008/10/15/3078996.aspx

3. A well-known translation of ASP. NET viewstate (truly understanding viewstate)

Http://blog.csdn.net/vividboy/archive/2008/01/28/2069347.aspx

4. ASP. NET developers must read -- post on viewstate and dynamic controls

Http://blog.joycode.com/saucer/archive/2006/09/28/84379.aspx

 

In fact, the research at the bottom layer is still in-depth and specific by foreigners. I have posted a few references on it, and I have referenced too many articles from foreigners. If you have the strength, you must check them. There will be no harm!