关于ViewState我曾经有过几篇博客的讨论《客观看待ViewState对Asp.net程序作用和影响》，《"Validation of ViewState Mac failed" exception》《回发事件执行很慢的问题.》。时过今日，我想从我目前的经验来总结，我们该如何来控制ViewState才是比较合理的。
ViewState是ASP.NET的一个独创设计。它为用户在进行Web开发时带来了极大的便利，特别是对于一个WEB开发新手来说，它完全可以不用自己去维护WEB控件的状态，在进行事件驱动开发时，用户只管通过控件ID来获取当前控件的值，而其它的细节ASP.NET都是对用户透明的，所以非常易于入门。而它所带的负面影响也是明显，有时候也是而严重的，最严重的就如上的那篇回发事件执行很慢，甚至时常出现“Validation of viewstate MAC failed”你也不会感到意外。
那么我们该如何来控制和使用ViewState呢？我想最好还是禁用它，但是也不绝对是这样的。你可以根据你的应用来决定是否禁用ViewState，那么决定因素有哪些呢？
1)你的生产环境，也就是说你是在哪里使用的。如果你的是在局域网内部，或是光纤到桌面（也不用光纤，速度有保证就行，这里只是一个比喻）。那么你可以放心使用ViewState。
2)你对Web开发的理解程度。这是主观因素，如果你对禁用ViewState有足够的控制能力，那么你可以放心的在web.config全局禁用ViewState。
3)如果你主观上能够接受ViewState，你希望能充分利用它给我们带来的便利。并且你可以很好的控制ViewState，不让它成为你的性能瓶颈。
4)你的应用场合，比如你如果是网站前台的话，那请尽量禁用ViewState。（当然也最好不要使用PostBack）
可能还有其它的原因来决定你是否使用ViewState。这里我们还是希望能够来总结一下ViewState带给我方便的同时，它都带了什么副产品给我们了：
1)最直观的就是页面体积。使用了ViewState，它会维护所有的控件的状态，在进行PostBack的时候，会适时的进行控件状态的还原。这是什么概念呢？就是控件的值（例如DropdownList里面的所有选项）除了通过HTML的方式显示给用户外，它同时在ViewState中还有一个备份，这个备份会以一个隐含变量的方式存在服务器发送的HTML代码中，同时在PostBack时会把这些ViewState再传回给服务器端。无形中增加了一倍以上的页面体积。
2)增加了体积了，自然就增加了网络传输。当然页面的反应速度就下降了。
3)在服务器端增加了一些额外的处理时间。ViewState增加了体积，那么对这些ViewState值的序列化和反序列化的发的时间也是不可小视的。另外，在还原控件状态时，需要对控件进行的遍历和赋值，这个时间也应该算是一个比较大的开销。
禁用ViewState，解决了一些问题。但是做为WebForm生命周期的一部分，那个ViewState处理函数还是需要被调用的，只是它们在判断EnableViewState==false以后，所做的事情就比较少了，也就节省时间了。如果你仔细查看一下禁用ViewState的页面，你还会发现有隐含变量__VIEWSTATE。如果你想让这个隐含变量也消失，那么你可以重写Page类的PageStatePersister，来达到这个目的。但是据我的经验，这样做以后好像会有一些其它影响，所以这里建议你尽量不要这样做（其实也没必要这么做）。
那么禁用了ViewState，是不是说我们就无法利用ViewState给我带来方便了？绝对不是这样的，正因为我们禁用了ViewState，那么我们就可以开始“滥用”ViewState了。因为有些情况下，我们需要在相同页面的不同的控件中使用一些相同的值。比如，你在查询完数据后，总页数也要在相同页面中的一些在其它控件里使用。这时因为不同控件不在同一个类中，无法使用变量传递，如果你放在缓存和Session中，那么冲突和过期时间就不是你所控制的了。这时我们就可以把它给存放在ViewState，因为ViewState的作用域仅限本页本次请求，页面输出后就随着页面实例而回收了。而因为我们禁用了ViewState了，这时我们在ViewState存的值并不会被序列化到客户端去。这样的“滥用”反而却会给我们的开发带来非常大的方便和灵活。
以上是我对ViewState的总结，可能有一些地方条理不是很清楚和重复，欢迎指正。
作者：阿不
