【转载】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. 除非跟踪一个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. 这同样适用于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! 如果你无论如何也要重新绑定数据，或者只是在回发时切换一个属性（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. 如果你确实需要使用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. 你也许认为在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. 你应该养成一个习惯：在默认情况下关闭所有控件的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);
    }
}