教你50招提高ASP.NET性能（二十）：7条便利的ViewState技巧

(32)Seven handy ViewState tips

招数32：

7条便利的ViewState技巧

Every time I have to deal with a classic ASP.NET Web Forms application, one of the first things I look at is the resulting source, to check whether the DOM is a complete mess and whether the ViewState is an enormous, unnecessary blob of ugliness. Usually, they indicate what kind of mess will be found further down the stack.
每次我不得不处理一个传统的ASP.NET Web Forms应用时，首先查看生成的源码，检查DOM是否一团糟、ViewState是不是很大，多余的丑陋代码块。一般，它们预示着发现的烂摊子会更烂。

<input type=”hidden” name=”__VIEWSTATE” id=”__VIEWSTATE” value=”/wFzY3JpcHQ6IE9uY2xpY2s9J3dpbmRvdy5vcGVuKCJFcXVpcG1lbnQtRGV0YWlscy5hc3B4P1VzZWQtMjAxMC1UZXJl…(continues for 18,000 characters)…UlVTIiB3aWR0aD=” />
<input type=”hidden” name=”__VIEWSTATE” id=”__VIEWSTATE” value=”/wFzY3JpcHQ6IE9uY2xpY2s9J3dpbmRvdy5vcGVuKCJFcXVpcG1lbnQtRGV0YWlscy5hc3B4P1VzZWQtMjAxMC1UZXJl…(此处省略18,000个字)…UlVTIiB3aWR0aD=” />

 

Inadvertently using ViewState when it’s not necessary substantially increases the amount of data going back and forth, and can lead to a greater prevalence of invalid ViewState exceptions; the bigger the blob, the more likely it could be interrupted in transmission and not be posted back in entirety in a post.
当没有必要大幅度地增长往来数据量时无心中使用ViewState，可能致使更大的广泛无效的ViewState异常；代码块越大，越有可能在传输中中断而且可能在一次提交中不彻底回发。

(33)Unless you’re tracking a Text_Changed event, you don’t need ViewState enabled on TextBoxes and similar controls. Classic ASP.NET automatically repopulates TextBox.Text values upon postback, even without ViewState enabled. Turn it off on each TextBox with EnableViewState= “false” on each one.

招数33：

除非跟踪一个Text_Changed事件以外，你不需在TextBoxes和相似的控件上要启用ViewState。传统的ASP.NET回发时会自动地填充TextBox.Text的值，甚至没有启用ViewState的状况下。在每一个TextBox使用EnableViewState=“false”关掉ViewState。

You can do this for other controls like labels, but unless you’re setting their values after the page’s load event, you won’t reduce the size of the ViewState.
你能够在其它控件像labels禁用ViewState，可是除非在页面加载事件后设置它们的值，你将不能减小ViewState的大小。

(34)The same goes for most implementations of Repeaters, ListViews, and so on. These are usually the biggest culprits and they can be ugly. The advantage of ViewState with these is avoiding having to populate values again in a postback.

招数34：

这一样适用于Repeaters, ListViews, 等等大多数的控件实现。这些一般可能成为丑陋的罪魁祸首。ViewState对于这些的优点是避免不得不在回发时从新填充值。

If you’re convinced that it’s worth passing ViewState back and forth again and again to save your app the extra database hit…well…you’re probably wrong. Save the database hit (if you need to) with some caching and disable that dang ViewState on that Repeater!
若是你相信这是值得一次又一次地回传ViewState以便节省你的应用程序额外的数据库访问...好...你可能错了。使用一些缓存减小数据库访问（若是你须要）而且在Repeater上禁用那见鬼的ViewState才是正道！

(35)If you’re re-binding data anyway, or just toggling one property on postback (asp:Panel anyone?), turn off that ViewState! Please!

招数35：

若是你不管如何也要从新绑定数据，或者只是在回发时切换一个属性（asp:Panel 任何一个），请关掉ViewState！

(36)If you do need ViewState, understand the page lifecycle and bind your data appropriately. A control loads its ViewState after Page_Init and before Page_Load, i.e. server controls don’t start tracking changes to their ViewState until the end of the initialization stage.

招数36：

若是你确实须要使用ViewState，理解页面的生命周期并适当地绑定数据。控件在Page_Init以后Page_Load以前加载它的的ViewState，也就是说，服务端控件在结束初始化阶段以前都没有开始跟踪ViewState的改变。

Any changes to ViewState mean a bigger ViewState, because you have the before value and the after value. So, if you’re changing or setting a control’s value, set it before ViewState is being tracked, if possible.
任何ViewState的更改意味着更大的ViewState，由于你得到更改先后的值。因此，若是你正在改变或设置控件的值，若是可能的话，设置它以前的ViewState是正在跟踪的。

(37)You may think it’s impossible to turn off ViewState on a DropDownList, even if you re-bind it on every postback. But with a tiny bit of elbow grease you can keep ViewState enabled and avoid passing all your option values back and forth. This is particularly worthwhile for DropDownLists with a big ListItem collection.

招数37：

你也许认为在DropDownList上关掉ViewState是不可能的，即时你在每次回发时从新绑定它。可是随着一点点的费力工做你可以保持ViewState的启用而且避免反复地传输全部的选项值。

One way is to turn off ViewState and bind the select value manually to the actual posted value, like so:
一种方法是关闭ViewState并手动绑定实际传输的选项值，像这样：

string selectedId = Request[Countries.UniqueID];
if (selectedId != null)
Countries.SelectedValue = selectedId;

 

However, you may prefer something I came across more recently. Instead of binding your DropDown-List in the typical Page_Load or Page_Init, bind it in the control’s Init event:
然而，你可能更喜欢我最近的一些尝试。在控件的Init事件上绑定事件，而不是在传统的Page_Load或Page_Init事件绑定你的DropDown-List。

<asp:DropDownList ID=”Countries” ...
OnInit=”CountryListInit” />
protected void CountryListInit(object sender, EventArgs e)
{
Countries.DataSource = // get data from database
Countries.DataBind();
}

 

(38)Make it your habit to turn off ViewState on every control by default, and only turn it on when you need it. If a page doesn’t need ViewState anywhere, turn it off at the page level.

招数38：

你应该养成一个习惯：在默认状况下关闭全部控件的ViewState，只有当你须要的时候打开ViewState。若是一个页面不须要任何ViewState，在页面级关闭它。

You do all that work to reduce requests, combine and compress static references, and make sure your code is as clean as possible - don’t ruin it with a ViewState monster! If you’re anal, you can completely remove all traces of ViewState from pages that don’t need it by inheriting from a BasePage such as this:
你作全部工做来减小请求，合并和压缩静态引用，并确保你的代码尽量的简洁 - 别让ViewState怪兽毁了它！If you’re anal（不知道怎么翻译），你能够继承一个基类页面，从页面彻底移除全部的ViewState跟踪，像这样：

/// <summary>
/// BasePage providing cross-site functionality for pages that should not have ViewState enabled.
/// </summary>
public class BasePageNoViewState : Page // Or of course, inherit from your standard BasePage, which in turn inherits from Page
{
    protected override void SavePageStateToPersistenceMedium(object viewState)
    {
    }
    
    protected override object LoadPageStateFromPersistenceMedium()
    {
        return null;
    }
    
    protected override void OnPreInit(EventArgs e)
    {
        // Ensure that ViewState is turned off for every page inheriting this BasePage
        base.EnableViewState = false;
        base.OnPreInit(e);
    }
}