ASP. NET efficiency trap -- attributes

As we all know, when compiling webcustomcontrol, attributes inherited from the basic class attributes of webcontrol and Its Attributes. cssstyle attributes are very common and important. But it is these two important attributes. Improper use during development will lead to inexplicable efficiency problems.

Due to the flexibility and incompleteness of HTML, The webcontrol base class does not fully display all the tag attributes and CSS Attributes provided and supported by HTML elements (of course, due to compatibility issues with different browsers, it is impossible to provide complete attributes ). Many HTML tag attributes and CSS attributes are very uncommon and rarely used. To provide complete support, webcontrol becomes a burden. Therefore, attributes and attributes. cssstyle solves this problem well. Of course, these two attributes not only support the HTML tag attributes and CSS attributes, but also support any valid custom key/value pairs. The question to be discussed here is the support for the custom key/value pair.

The type of the attributes attribute is an attributecollection, which is a natural thing, but I don't know how to do it. The attributecollection constructor needs a statebag parameter:

Public attributecollection (statebag bag)
{
This. _ bag = bag;
}

The result is that attributes and attributes. cssstyle may be stored in viewstate. In fact, ASP. NET does save the content to viewstate by default.

This kind of design is really confusing. During discussions on viewstate efficiency, we thought viewstate was indeed a weakness, so it was easy to maintain some server states and data. However, it is crazy to store all the content related to the UI into the viewstate.

The following describes how to use attributes to define viewstate after custom content:

// Custom content is defined on the analysisreport custom control.

After attributes and attributes. cssstyle are automatically saved to viewstate, the load of viewstate increases at the same time after the viewstate volume increases rapidly. The loadstate cost of page PostBack in the above example, for example:

In fact, when writing controls, I never thought about maintaining attributes and attributes. cssstyle, or trying to use the data again. In addition, this default save to viewstate behavior can not be customized (at least I have not found), and later thought in ASP. NET page survival period, savestate ends in prerender, so attributes and attributes are used in the render event. cssstyle will not be saved to viewstate.

Modify code: protected override void onprerender (eventargs E)
{
This. attributes ["ABC"] = "123 ";
This. Attributes. cssstyle ["ABC-style"] = "123-style ";
Base. onprerender (E );
}

Format: protected override void render (htmltextwriter output)
{
This. attributes ["ABC"] = "123 ";
This. Attributes. cssstyle ["ABC-style"] = "123-style ";
Output. Write (text );
}

Attributes and attributes. cssstyle will no longer be saved to viewstate. After the above analysisreport is modified according to the above example, the running effect of binding the same data is:

The loadstate cost is also greatly reduced, and its overhead is: