转自:http://blog.csdn.net/vividboy/archive/2008/01/28/2069347.aspx

概述

ViewState是一个被误解很深的动物了。我希望通过此文章来澄清人们对ViewState的一些错误认识。为了达到这个目的，我决定从头到尾详细的描述一下整个ViewState的工作机制，其中我会同时用一些例子说明我文章中的观点，结论。比如我会用静态控件(declared controls)和动态控件(dynamic controls)两个方面来说明同一个问题。

现在有关ViewState的文章可谓多如牛毛，你可能会说再写有关ViewState的文章无异于炒剩饭.但是我却不这么认为，如果把ViewState看成一匹野马的话，那么这匹野马并没有死去，它还活跃的很，说不定这个时候它正在你的客厅里撒野呢。所以我们有必要再次去把它击倒。不过你也不需要担心，从这篇文章你可以发现其实这匹马也没有那么坏。

我的意思并不是否定目前还没有好的说明ViewState的文章，只是我总觉得好像这些文章都缺少一些东西，而这些缺少的东西往往就会导致人们对ViewState的困惑。比如：理解ViewState是怎样跟踪那些已经出现变化的数据(dirty data)就非常重要，但是很多文章却没有过多的涉及，或者即便涉及了可能其中却包含了错误的信息。比如这篇文章(W3Schools)中就说页面回传的值也是保存在ViewState中的，但是这个观点是错误的。不信是吗？那么你在一个页面上放置一个TextBox控件和一个Button控件，然后你在“属性”中将TextBox的EnableViewState设置为False,然后通过点击Button回传页面，你会发现TextBox还是仍旧会保留你输入的值，而不会如你想象的由于TextBox的ViewState被禁用了而导致TextBox的值在页面回传的过程中消失了。还有一些文章(#1 Google Search Result , ASP.NET Documentation on MSDN )描述了服务器控件如何在页面的回传中保持自身状态。这些文档虽然没有全错，但是有些描述还是存在一些不准确的地方，如：

"If a control uses ViewState for property data instead of a private field, that property automatically will be persisted across round trips to the client."

（如果一个控件用ViewState而不是用类的私有字段(private field)来存储数据，那么这些控件属性的值将会自动在页面回传之间保持状态.)

上面这句话似乎在暗示任何东西只要是保存在ViewState 状态包(StateBag)中，那么就会在服务器和客户端页面回传的过程中被传递。(That seems to imply that anything you shove into the ViewState StateBag will be round-tripped in the client's browser. NOT TRUE!)不对！所以说对于ViewState控件的困惑还是存在的。而且在Internet上我目前还没有找到一篇100%准确完整的描述ViewState工作的文章。我目前找到的最好文章是这一篇(this one by Scott Mitchell)。这篇文章是值得一读的。然而这篇文章还是有些美中不足，它没有描述在控件初始化和ViewState跟踪的时候父控件和子控件之间的关系。而恰恰就是这一点就会导致对ViewState大量的误解，至少我是有过这种经历的。

根据上面的情况，这篇文章从最开始先会对ViewState实现的功能进行一个完全描述。然后对ViewState的实现进行一个详细的阐述，在这个过程中我会同时举一些相对应的例子，通常我会先举一个开发人员经常会犯的错误的例子，然后再举一个例子来表示如何修正错误。在这里我需要实现声明一下的是，虽然在ASP.NET 2.0中ViewState的实现机制有稍许变动，但是在写这篇文章的时候我依然是以ASP.NET 1.x的版本为前提进行的。比如说在ASP.NET 2.0的新增了一个新类型的ViewState -- ControlState, 但是实际上ControlState和ViewState并不大变，所以我们这里可以忽略它。

首先让我们看看为什么深入了解ViewState是如此重要。

对ViewState的误解可能导致...
1.导致一些敏感信息被泄漏；
2.针对ViewState的攻击(aka the Jedi Mind Trick，aka 是又称作，又叫做的意思。Jedi Mind Trick, 看过星球大战的人对于Jedi一定不陌生，Jedi就是绝地武士。Jedi Mind Trick 是绝地武士的一个招式，可以用于控制对方的思维。有关这个的具体知识可以参见：http://gollum.easycp.de/gollum/gollum.php?a=core&l=en&wl=en&q= 这里作者估计是表达了通过ViewState的攻击来达到控制对方的目的。比如一个等离子电视的价格被修改为了1美元一台)
3.很差的性能，在某些极端的情况下可能根本就没有性能。
4.并发性差 -- 想象一下如果每次回传的数据都有50kB，那么你的服务器能承受多少并发的访问量呢？
5.糟糕的全局设计；
6.以上结果一定会让你抓狂的(头痛，反胃，头昏眼花，皱眉头...)。
如果你正在开发基于ASP.NET平台的网络应用程序，并且你无视ViewState存在的话，那么以下的情况可能会发生在你的身上。

The ViewState form field.

ViewState will add your web app's distinctiveness to it's own. Performance is futile. 

像如上的例子我还可以举出很多，但是我想这两个例子已经具有代表性了。好了，现在让我们从最开始认识ViewState吧。

ViewState可以用来做什么？
这里列举的每一项都是ViewState需要完成的主要工作，我们将根据这些工作来学习ViewState是如何实现这些功能。
1.以名值对的方式来存控件的值，和Hashtable的结构类似；
2.跟踪那些ViewState中出现改变的值，以便对这些脏数据(dirty)进行进一步的处理；
3.通过序列化将ViewState中的值保存在页面的隐藏域(Hidden Field)中(这是默认的持久化方式)，并通过反序列化得到对应的ViewState对象以便进行相应的操作；
4.在页面回传的过程中自动的存储ViewState中的跟踪的值。
下面列举的是ViewState不能用来做什么的列表，这个其实比了解ViewState是用来做什么的还重要。

什么是ViewState不能做的？
1.自动保存一个类中变量的状态，无论是private, protected还是public的变量；
2.可以在页面回传的过程中记住所有状态值；
3.只要有了ViewState那么每次页面请求时重新构造的数据的操作是不必要的了；
4.ViewState is not responsible for the population of values that are posted such as by TextBox controls (although it does play an important role) ViewState并不存储那些通过Post名值对回传的数据值(如TextBox的TextBox.Text)；
4.想让ViewState替你泡一杯咖啡，

虽然ViewState作为一个整体出现在.NET Framework框架中有它的唯一目的，那就是在页面回传的过程中保存状态值，使原本没有“记忆”的Http协议变得有“记忆”起来。但是上面列举的ViewState的四个主要功能之间却没有太多的关联。所以从逻辑上我们可以将其划分开来，各个击破。

Mmm...，这样大小的ViewState是不是更加好下口了？

1. ViewState就是用来存储数据的

如果你曾经使用过HashTable的话，那么你应该明白我的意思了。这里并没有什么高深的理论。ViewState通过String类型的数据作为索引,ViewState对应项中的值可以存储任何类型的值，实施上任何类型的值存储到ViewState中都会被装箱为Object类型。以下是几个对ViewState进行赋值的几个例子。

ViewState["Key1"] = 123.45M; // store a decimal value

ViewState["Key2"] = "abc"; // store a string

ViewState["Key3"] = DateTime.Now; // store a DateTime 

实际上ViewState仅仅就是一个定义在System.Web.UI.Control类中的一个保护类型(Protected)的属性名称。由于所有服务器端的控件，用户自定义控件还有页面(Page)类都是继承自System.Web.UI.Control类，所以这些控件都具有这些属性。ViewState的真正类型实际应该是System.Web.UI.StateBag类。严格的说，虽然StateBag类虽然定义在System.Web的命名空间下，实际上StateBag类和ASP.NET并没有严格上的依存关系，它也完全可以放在System.Collections命名空间下。事实上许多服务器端控件大多数属性值都是利用ViewState来进行数据存储。

你可能认为TextBox.Text属性是按如下形式存储的：

public string Text {

        get ...{ return _text; }

        set ...{ _text = value; }

}

但是你必须注意，上面的形式(通过类的私有字段)并不是大多数ASP.NET 服务器控件存储其属性值得方式。这些控件的属性值大多是通过ViewState来进行存储的。

通过Reflector查看TextBox.Text属性的源代码你可以看到类似如下的代码：

public string Text { 

       get ...{ return (string)ViewState["Text"]; } 

       set ...{ ViewState["Text"] = value; }

}

为了表示这个观点的重要性，我这里再重申一遍“大多数ASP.NET 服务器控件存储其属性值得方式是通过ViewState的方式存储的，而不是我们通常想象的那样通过类的私有字段来存储。”

即便是用于设定服务器控件样式的Style类中的大多数属性值也是通过ViewState来进行存储的。所以在设计自定义的组件时，对于那些需要存储的组件属性值也最好遵循这个方式。这里我还需要着重讲一个问题，在以ViewState为存储方式的情况下，如果实现属性的默认值(default value)，我们可能会认为属性值是这样实现的：

public class MyClass
{  
      private string _text = "Default Value!";    
      public string Text
     {      
           get { return _text; }       
           set { _text = value; }   
     }
}

这样如果在对Text的属性没有设置的时候，直接取Text属性，那么我们可以得到默认值"Default Value!"。那么如果我们使用ViewState来存储的时候如何实现默认值呢？如下所示：

public string Text {

         get {  return ViewState["Text"] == null ? "Default Value!" :  (string)ViewState["Text"];          }   

         set {   ViewState["Text"] = value; }

}

就像操作HashTable一样，如果StateBag(ViewState)中没有包含某个键值的项，那么它会返回一个null(在VB.NET中是返回Nothing)。所以我们可以通过判断对应键值的项是否是null来判断某个ViewState项是否被赋值。然后我们通过三目运算符来根据实际情况来返回默认值或者设置的值。并且使用三目运算符实际上这里还出于一个考虑，那么就是在服务器控件中，如果将某个属性值设置为空(null)，那么往往代表的意思是使用此属性的默认值。所以第一种实现方法还存在一个问题，那就是如果把某个属性值设置为null,当我们再取这个属性的时候我们将得到null，而不是我们期望的"Default Value!"了，所以对于第一种实现方法还需要对null这个特殊值进行判断才可以完全满足需求。ViewState还可以被用作其他的作用，比如在页面回传过程中保留某些值，比如我们在页面后台代码中常常使用ViewState("Key") = "SomeValue"的方式来存储值，实际上就是使用了Page类的ViewState属性来进行值得存储。同样的我们也可以在控件级别进行ViewState的值定义存储。但是由于这是另外一个话题，和我们现在所要描述的东西没有太多关系，所以这里就不再详细说明下去了。

2. ViewState可以跟踪值的变化

你知道吗？如果你设置一个控件的属性值，那么你会把ViewState中这个属性值对应的数据弄脏(dirty)的。当然这里的脏数据和数据库中的脏数据不同，这里的脏可以理解为“发生变化”的意思。你知道为什么StateBag会存在，而不会被HashTable取代吗？前面我们可是大肆宣扬了一下StateBag和HashTable有多么的像。虽然他们都是通过名值对的方式来存储值，但是StateBag还具有对其中数据更改的跟踪能力(Tracking ability)。追踪可以开也可以关,我们可以通过调用StateBag.TrackViewState()方法将追踪功能开启。只有在跟踪的开关设置为“开”的情况下StateBag中的数据更改才会被跟踪，只要数据出现修改，那么对应StateBag项的数据将会被标记为“脏的”(dirty)。StateBag还提供了检查一个数据项是否是脏数据的方法 IsItemDirty(string key)。你也可以在不更改项数据数值的情况下将对应项设置为脏数据，这里需要使用SetItemDirty(string key)方法。

为了说明这些，我们看一下以下的例子。这里我们假设当前的StateBag跟踪的开关是处于关闭状态的。

看到上面的例子应该很清楚了，在调用了TrackViewState()方法后，StateBag开始跟踪其所包含项值的变化。之前无论你如何修改StateBag中项的值，都无法把数据弄“脏”的。而且这里还需要注意一点，在TrackViewState()方法调用后，只要是出现了赋值操作那么就会使其被标记为脏数据，StateBag并不会判断赋值前后对应项的值是否出现了变化。如下例子所示：

可能你会认为根据赋值前后ViewState是否存在变化然后再标记是否是脏数据这样更加符合常理。但是必须注意的是ViewState的项是可以存储任何类型的值的(实际上任何赋值给ViewState的变量都会被装箱为Object类型的变量)，所以比较赋值前后的值是否一致实际上并没有变面上看的那么容易。而且不是每种类型都继承了IComparable的接口，所以通过调用CompareTo方法来进行比较也是不可行的。另外还有一个原因，我们知道ViewState还需要将其内部的数据进行序列和反序列化，当这些操作发生后，你得到的对象已经不是原来那个对象了，所以比较对象之间的引用也是无法完成的。基于以上这些原因，ViewState采取了一种简单的做法，也就意味着ViewState的数据变化跟踪也是一个简要的跟踪。

到这里你可能会想在设计StateBag类的时候为什么要使其具备跟踪数据变化的能力呢？我们为什么要跟踪那些出现变化的项呢？(Why on earth would anyone need to know only changes since TrackViewState() is called? Why wouldn't they just utilize the entire collection of items? )，这个疑问往往是造成对ViewState困惑的根源。基于这个问题我曾经和很多人交谈过，其中不乏有着多年ASP.NET开发经验的专家，但是很遗憾，我没有从任何一个人那里得到我满意的答案。没有一个人能够解释清楚为什么StateBag对数据变化的跟踪是必要的。为了解释清楚这个问题，我们首先需要先了解一下ASP.NET是怎样建立静态控件的。所谓静态控件(declarative control)就是那些从页面或者用户自定义控件的源码中可以看到声明代码的控件。如：

<asp:Label />

这里在页面上声明了一个Label控件。然后ASP.NET会解析这段代码，它首先会查找那些标签中带有“runat=server”的代码，然后根据类型创建对应的控件对象，接着将标签中设置的控件属性值一个一个地赋值到控件实例对象中。比如例子中我们设置了Label对象的Text属性，那么在解析的时候就会存在一个类似于：lbl1.Text = "Hello World"的赋值过程。通过反射机制，ASP.NET可以知道对应的类型是否具有对应的属性，对应的属性是什么数据类型。这里Text属性的数据类型是String型，对于数据类型不是String的属性，那么在设置属性前ASP.NET必须实现进行String到对应数据类型的转换。如：TextBox控件可以设置Width属性，但是Width是Unit类型的，所以这里就设计到一个从String到Unit类型的转化过程。

好，到了这，我们再以前面所说的内容将当前发生的事情再描述一遍。我们已经知道大多数服务器控件的属性值最终是存储在ViewState中。而且如果ViewState已经开启了跟踪数据，那么此次属性的赋值就会导致“脏数据”的产生，但是如果ViewState还没有开启跟踪数据，那么脏数据的标记值就一直为False。现在问题就是在当前ASP.NET解析静态控件的时候是否开始跟踪和是否产生了“脏数据”呢？答案是，没有。原因是此时的ViewState赋值之前ASP.NET并没有去调用TrackViewState()方法，所以ViewState是不会对数据的更改进行跟踪的。事实上ASP.NET是在页面生命周期的OnInit阶段才调用TrackViewState()方法的。这样做的目的就是让ASP.NET可以很方便的区分控件的哪些属性值在初次声明后仍未改变，那些属性值已经被改变了(可能是程序的方式也可能是人工输入的方式)。如果到目前为止你还没有意识到这个观点很重要的话，那么请继续往下读吧。

3. 序列化和反序列化(SERIALIZATION AND DESERIALIZATION )
我们先把ASP.NET怎样解析生成静态控件放一边，我们前面提到的ViewState的两个重要功能(1. ViewState可以像HashTable那样通过名值对来存储值；2. ViewState可以对那些修改的数据进行跟踪。 )现在我们将来讨论另外一个话题，那就是ASP.NET是怎样通过StateBag类的特性来实现那些看似诡异的功能的。

如果你在ASP.NET中使用过ViewState，事实上我相信只要是ASP.NET的开发者都会使用过ViewState了。而且可能你也知道了序列化(serialization)的问题。如果是默认的方式，那么VIewState中的值会被序列化成一个基于Base64编码的字符串，然后存储在页面中一个叫做_ViewState的隐藏变量中。

这里在继续之前，我需要稍稍叉开一下话题先说一些页面的控件树。我发现有不少有多年ASP.NET开发经验的程序员还不知道控件树的存在。由于他们仅仅是对.aspx页面进行操作，所以他们仅仅只关心那些页面上声明的控件。但是我们必须认识到页面的控件实际是以一颗控件树存在的，并且控件中还可以包含子控件。这颗控件树的根节点就是页面本身(Page)，然后树的第二层通常是包含3个控件，它们分别是用于保存表单(<form>)标签前所有信息的文本控件(Literal)，然后是表单控件(Form)，然后是表单(</form>)标签后面的所有信息的文本控件(Literal)。接着是树的第三层包含的控件就是在表单标签内声明的那些控件，如果这些控件中还包含子控件，那么这颗控件树的深度将会不断的加深，一直到所有页面的控件都被包含在这颗控件树中。每个控件都会有自己的ViewState对象，并且由于这些控件共同的基类(System.Web.UI.Control)中包含一个受保护(protected)的方法SaveViewState，方法的返回值是一个Object变量。在Control.SaveViewState方法中如果发现ViewState不为空，那么就直接调用其私有变量_viewState(StateBag类型)的SaveViewState方法。通过阅读这个方法，可以发现其作用就是将ViewState中被标记为脏数据(dirty)的项的键和值都存储在一个ArrayList中，然后再将这个ArrayList进行返回。通过递归的方法遍历整个控件树的各个节点，并递归的调用各个控件的SaveViewState方法，这样当整个控件树被遍历完成以后，那么和控件树一一对应的会形成一个由ViewState的值组成的数据树。

在这个阶段，ViewState中存储的数据还没有被转化为我们在_ViewState隐藏变量中存储的Base64编码的字符串。这里仅仅是形成了一颗需要被持久化存储的数据树。这里再强调一下，存储的数据是ViewState中那些被标记为Dirty的项。StateBag类具有跟踪功能就是为了在存储的时候判断哪些数据需要被存储，哪些数据不需要被存储(实际上这是StateBag具有跟踪数据功能的唯一原因)。很聪明是吧，但是如果使用不当的话，在ViewState中依然可能保存一些不必要的数据。我会在后面的例子中来说明这些可能犯的错误.

突击测试(POP QUIZ)
如果你已经读到了这里，那么祝贺你，我要奖励一下这么有毅力的你。咱们来个突击测试如何？我是不是人很好呢？哈哈。题目是这样的，我们有两个几乎一模一样的.aspx页面，我们分别称之为Page1.aspx和Page2.aspx, 每个页面都存在一个form，其中包含一个Label控件，如下所示：

这两个页面唯一的区别是Label中包含的值不同(Label.Text的值)。Page1.aspx中的label1.Text = "abc",如下代码所示。<asp:Label />
那么对于Page2.aspx中的Label，我们对其多赋一点值(就来个美国宪法的序言吧)。如下代码所示。

<asp:Label />

现在我们在浏览器中运行Page1.aspx，那么我们将看到一个abc。然后你通过浏览器查看页面的HTML源码，你可以找到那个“臭名昭著”的隐藏字段(_ViewState)。然后把Page1.aspx的_ViewState值保留下来。接着运行Page2.aspx，同样保留其_ViewState的值。然后比较这两个ViewState的大小(注意：这里比较的是大小，或者说比较字符串的长度，而不是内容)。问题来了，请问这两个ViewState的大小是否一样呢？好了，在公布答案之前我们再去看看另外一个问题，我们在两个页面上都增加一个Button控件，这样通过点击Button按钮我们就可以回传页面了。一下就是页面中声明Button控件的代码：

<asp:Button />

这个Button并没有任何的Click事件处理函数，仅仅用于将页面提交服务器。我们再重复上面的实验，唯一不同的是，我们这回是在点击了Button后再去查看各自得_ViewState的值，我们的问题还是一样的，请问这两个ViewState的大小是否一样呢？好，现在揭晓正确答案。第一个问题的答案是：是的，两个页面的ViewState的大小是一样的。原因是这当前这两个ViewState中并不包含任何和Label有关的数据。前面我们知道所有需要存储在_ViewState中的数据都必须是被标记为Dirty的脏数据。而需要启动对ViewState中各项数据的跟踪，必须先要调用TrackViewState()方法，什么时候调用TrackViewState方法呢？是在页面生命周期中的OnInit阶段，而由于Label控件中的Text是在页面中静态声明的，所以在AddParsedSubObject阶段(早于OnInit阶段)Text值就已经被赋值到对应Label控件中了。所以这些Text中的值将不会被标记为Dirty，同时也不会被保存在_ViewState中。所以无论Label.Text有什么不同，那么其页面的_ViewState始终是相同的。那页面中那一小段的_ViewState到底包含了什么信息呢？你可以用ViewState Decoder工具查看一下，可以发现在这样一个简单的界面，_ViewState仅仅包含了页面的哈希代码(HashCode)。

好，让我们到第二个问题(页面加了Button那个情况)，答案同样是：是的，它们的大小也是一样的。原因和上面解释的一样。简单的说就是在TrackViewState()方法后面并没有对Label.Text属性进行赋值操作，所以ViewState中的项并没有被标记为Dirty,自然就不会被序列化并记录到_ViewState隐藏变量中了。

到此为止我们已经基本了解了ASP.NET平台是怎样决定一个数据是否需要被序列化并永久保留在_ViewState中了(那些被标记为Dirty的数据)。至于ASP.NET是怎样序列化这些数据的已经不是本文的范围了，如果你有兴趣进一步了解的话，那么请参看如下两篇文章： LosFormatter for ASP.NET 1.x  和  ObjectStateFormatter for ASP.NET 2.0。

在这一个小节的最后，我们要简单的说说反序列化。反序列化和序列化是相对应的，如果不能通过反序列化来将序列化的对象进行还原，进行操作的话，那么序列化操作将没有任何意义。但是这是另外一个话题，所以这里就不再进行赘述。

4. 自动恢复数据(AUTOMATICALLY RESTORES DATA)
到此为止我们已经说到了ViewState最后一个功能，那就是自动恢复数据。有些文章将这个过程和上面提到的反序列化过程混淆在一起，这样的理解是不正确的，实际上自动恢复数据的过程并不是反序列化过程的一部分。ASP.NET首先反序列化_ViewState中的值，将其还原为对象，然后再将这些还原的值重新赋值给其对应的控件。

作为所有控件包括Page类基类的System.Web.UI.Control类型中包含一个LoadViewState(object savedState)方法。其中需要被载入的数据就是通过参数savedState进行传递的。LoadViewState和前面所说的SaveViewState是相对应的方法。而且和SaveViewState方法类似的是，Control.LoadViewState也是简单的调用了StateBag中的LoadViewState方法。通过查看LoadViewState的源代码可以发现，这个函数实际就是将savedState中存储的名值对重新Add到StateBag列表中(StateBag.Add(key, value))。同时我们从LoadViewState也可以发现在.NET Framework 1.1中传入的object变量是一个pair类型的变量。pair类型包含两个属性First, Second都是object类型的变量，在ViewState中其中一个属性存储的是包含ViewState.Item.Key的ArrayList而另外一个属性包含的是ViewState.Item.Value的ArrayList，相对应的Key和Value在ArrayList中的下标相同。然后StateBag类就通过遍历两个ArrayList将值添加到状态项中(注意在.NET Framework 2.0中这个方法的实现有些小小的改动，放弃使用Pair类型而仅仅使用一个ArrayList, ArrayList中每个名值对占两个Item, 前一个为key后一个为value, 循环的时候以步进2进行循环)。这里需要注意的是从LoadViewState()重新载入到ViewState的数据仅仅包含前一次请求被标记为Dirty的那些数据(注意不是当次请求(current request)，而是前一次请求(previous request)就是当前请求的前一次请求。)在载入_ViewState中包含的数据之前，对应控件的ViewState中可能已经包含了一些值了，比如那些静态控件中预先声明好的值(如：<asp:Label Text="abc"/>中的Text属性在LoadViewState()之前就已经是"abc"了)。如果LoadViewState()中需要载入的数据中已经存在值了，那么对应的值将被新值所覆盖。

为了让大家有一个完整的认识，这里将页面回传以后发生的事情再简单的描述一下。首先页面回传以后，整个Page将重新生成并且那些页面上声明的静态控件也都已经被解析添加到以Page为根节点的控件树中，那些静态控件对应的静态声明的属性值也都被初始化。然后是OnInit阶段，在这个阶段ASP.NET会调用TrackViewState方法，从此以后所有对控件属性的赋值操作都将导致被跟踪。接着就是LoadViewState()方法被调用，这里那些从_ViewState中反序列化出来的值将被重新赋给对应的控件，由于在此之前TrackViewState()已经被调用了，_ViewState中包含的数据对应的属性值都会被标记为Dirty。这样当调用SaveViewState的时候，这些属性值还是会被持久的保留到_ViewState中，这样在页面的一次次回传和页面一次次的重新建立的过程中，这些控件的值就被保留下来了。现在是不是有种豁然开朗的感觉？恭喜你，你现在已经是一个ViewState管理的小小专家了:)。

一些常见的ViewState使用错误(IMPROPER USE OF VIEWSTATE)
到目前为止我们已经大致了解了ViewState运行机制了，我们可以再次回顾一下我们在使用ViewState中的一些错误，然后分析其原因。有些错误在你了解了ViewState以后是显而易见，但是有些错误却比较隐蔽，但是通过对这些错误的深入分析将会让你对ViewState有进一步的了解。 

            错误使用ViewState的情况(CASES OF MISUSE)

1.为服务器端控件赋默认值(Forcing a Default);
2.持久化静态数据(Persisting static data);
3.持久化廉价数据(Persisting cheap data);
4.以编码的方式初始化子控件(Initializing child controls programmatically);
5.以编码的方式创建控件(Initializing dynamically created controls programmatically)。
1. 为服务器端控件(webcontrol)设置默认值(Forcing a Default)

注：这里我个人认为原文的例子存在问题，所以我这里按照自己的理解来写。大家如果看了原文有不同的理解的话，欢迎和我进行交流。

这个错误是开发服务器端控件(WebControl)中最常见的错误，不过这个错误修改起来非常的简单，而且修改后的代码会更加的简洁明了(事情往往就是这样，越正确的方式，越优的方式往往也是最简明的方式)。造成这种错误的原因往往是开发人员没有了解ViewState的跟踪机制或者根本就不知道有跟踪机制这种说法。我们来看一个例子，我们现在有一个控件，这个控件有一个Text属性，如果没有对Text进行赋值，那么就从一个Session变量中得到其默认值。我们的程序员Joe写下了如下代码：

注：这里我将if (!this.IsPostBack) 的条件设置为if (this.Text == null)就是指当Text属性没有赋值时，那么就赋初值。)

以上代码存在一个问题，第一个问题是Joe花了大力气为控件设置一个Text，他希望使用者可以对这个控件赋值。Jane是其中一个使用者，她写下了如下的代码：

<abc:JoesControl />

当Jane查看其页面HTML源代码的时候，她发现她的页面ViewState的体积也变大了。天哪，要知道Jane的页面上仅仅只有Joe的那个控件了。得了，你知道世界上的男女关系啦，Jane肯定是去让Joe去修改他这个蹩足的控件了，不过让人高兴的是这回Joe修改后的控件似乎工作的很好了。这就是Joe的第二次实现方式：

看看这段代码，多么简洁!而且Joe也不必再去重写控件的OnLoad方法了。这个时候Jane再次使用了这个控件，当Jane设置了控件的Text属性时，她将得到她先前设置的值。如果Jane没有设置值，那么她将得到Session["SomeSessionKey"]中存储的默认值。并且Jane也发现她的页面HTML源码的ViewState大小并没有因为添加了Joe的控件而增加。大家都很开心！那么前面的代码为什么会存在问题呢：

1. 为什么第一种实现方式会使页面的ViewState大小变大？

这里先要说明的是，如果在使用JoesControl的时候赋了初值，如下：

<abc:JoesControl ]并不会被标记为Dirty，当然也就不会记录到_ViewState中进行持久化。所以第二种实现方式是优于第一种实现方式的。

2. 持久化静态数据(Persisting static data)

我们这里所说的静态数据是那些不会被改变的数据(never change)或者在页面的生命周期中、一个用户会话中不会被改变的数据。还是我们可爱的程序员Joe，最近他又接到了一个改造网站的任务，在他们公司的eCommerce网站上显示那些已经登录的用户，比如“嗨，XXXX，欢迎回来！”Joe的前提条件是这个网站已经有了一个业务层的API,可以通过CurrentUser.Name的方法方便的得到当前已经验证的用户姓名。剩下的把这个人名显示到页面上的工作就看Joe的了。以下是Joe的代码：

好了，F5，运行，一切正常，Joe又开始得意洋洋了。但是我们知道其实这里Joe还是犯了个错误。用户的名称不仅仅会显示在Label中，同样还会被序列化到_ViewState中，并根据页面/服务器之间的来来回回而不停的被序列化、反序列化...。这个开销是值得的吗？Joe耸耸肩说，这有什么关系，就那么几个字节而已。但是可以节约一点为什么不节约呢，而且解决的方法还是如此的简单。第一种方法，不用修改源代码，直接禁用Label控件的ViewState，如：

<asp:Label />
好了，问题解决了。但是是否有更加好的解决方法呢？有！Label控件可能是ASP.NET中最最被高估的控件了。这个可能是由于那些WinForm的VB编程者，在WinForm中如果要显示一些文本信息，你可能需要一个Label。而ASP.NET中的这个Label可能被认为和WinForm中的Label是等价的了。但是真的就是这样的吗？通过HTML源码我们可以看到Label控件实际被解析成了HTML中的<span>标签。你必须问问你自己是否真的需要这个<span>标签呢？如果不需要涉及到特定的格式，仅仅是显示信息那么我觉得答案是否定的。请看：
<%= CurrentUser.Name %>

恩，这样你就可以避免生成一个<span>标签了，并且可以很好的解决问题。但是从编程习惯上来说，这种将前台和后台代码混合的形式是不提倡的，这样会使代码的可读性下降，并且使开发的职责无法明确区分。所以这里还可以使用一种ASP.NET中存在但是确被Label控件的光环笼罩的控件 -- Literal。这个控件仅仅将其Text中的内容输出到客户端，并且不会生成<span>标签。是不是觉得对这个控件有些印象，对了，前面在说道将页面解析成一个控件树的时候，第二层一般由三个控件组成，一个是Literal，用于存储到<form>标签以前的所有html代码。就是这个控件。以下就是使用Literal控件来替代Label控件的方法。当然这里也需要将EnableViewState设置为false。问题解决了的同时，我们节省了网络传输的资源。不错!

<asp:Literal />

3. 持久化廉价的数据(Persisting cheap data)

这个问题实际上包含了第一个问题。静态数据往往是很容易就可以得到的(取得的开销/成本比较小)，但是并不是所有容易取得的数据都是静态数据。可能这些数据会不停的被更改，但是总体来说得到这些数据的成本很低。一个典型的例子是美国各个州的列表。除非你要回到1787年12月7日(here)，那么当前美国的所有州列表在短期内是不会有改变的。当然我们现在的程序员都很痛恨硬编码。“让我把美国各个州的列表都静态的写在页面上？傻子才这样做呢。”我们更加倾向于将州名都保留在一个数据库(或者其他易于修改的配置文件中。)，这样如果州名或者州的列表出现了任何变化，就不用修改源代码了。恩，我完全同意这一点，我们的著名程序员Joe也是这样认为的，而且这张表在他们公司已经存在了，表名叫做USSTATES，这回Joe的任务就是和操作这张表有关系的。下面是用于显示美国各个州列表的下拉菜单(DropDownList)：
         <asp:DropdownList />
        这里显示的是绑定从数据库中取得的美国州列表的数据代码：

由于美国50个州是在OnLoad阶段中被绑定到下拉菜单(DropDownList)中的，所以这些信息在绑定到下拉菜单的同时，还被序列化并被记录到了ViewState中了。天哪，那可能一个庞大的数据，特别是对于那些低速接入网络的用户。你知道吗，我好几次都想给我的奶奶讲解为什么网络这么慢(那是因为你的电脑正在请求所有美国的州呢，能不慢吗？)，但是我想我的奶奶是不会懂了。我想她可能会开始跟我说，在她年轻的时候美国只有46个州。那4个新增的州，真是可恶，它们拉慢了我们的网络。但是我们又有什么办法呢？(我们可都是平民百姓。:D)

这个问题和上面提到的静态数据有些类似，一种比较通用的解决方法就是将控件的EnableViewState属性设置为False。但是这种解决方法并不是万能药，比如我们现在的例子，如果Joe仅仅是将用于显示美国各州的DropDownList的EnableViewState控件设置为false，并且将OnLoad函数中的!Page.IsPostBack的限制条件去掉(这样就保证每次载入页面后DropDownList都会被重新绑定，而不会再页面回传以后导致DropDownList中的数据丢失。)，那么在使用的时候，Joe就会发现他有麻烦了。什么麻烦呢？“当页面回传以后，Joe发现他先前选择的州并不是下拉菜单(DropDownList)中的默认值。”(注意这里的DropDownList是静态控件才会出现上面说的这种情况，如果是在OnLoad中动态生成的DropDownList控件然后再绑定数据那么不会出现此问题)怎么会这个样子！！这是对ViewState的另外一个误解。下拉菜单之所以没有保留页面回传前的选择值并不是因为我们禁用了下拉菜单的ViewState。在页面回传的时候还有一些用于获取页面信息的控件值并不是通过ViewState来进行保存的，他们是通过名值对的方式通过Http请求(HttpRequest)的方式进行回传的，这些值被称为回传值(PostData)(可以通过将回传方式修改为GET来从URL中查看存在哪些回传值)。所以即便是我们禁用了DropDownList的ViewState，DropDownList依然可以将那个选择的值回传服务器。这里之所以下拉菜单(DropDownList)会在页面回传后“忘记”上次选择的值是因为在OnLoad阶段之前的ProcessPostData已经对DropDownList设置了默认值，但是这个时候DropDownList还没有ListItem，自然无法设置到最后一次回传选择的值。然后是OnLoad事件中对DropDownList进行数据绑定，但是由于没有执行ProcessPostData方法所以不会再次设置默认值。前面的括号中有说明，如果这个DropDownList控件也是在OnLoad中动态生成的，那么由于进度追赶，在OnLoad阶段后还会重新执行一次ProcessPostData，在这里又会把下拉菜单中的值设置为默认值，所以说以上描述的问题仅仅只有在DropDownList为静态控件的时候才会存在。幸运的是我们解决这个问题的方法也很简单，我们将绑定数据的代码移动到OnInit阶段，这个阶段将先于ProcessPostData执行，所以下拉菜单将被设置为最后一次回传的默认值。
 

上面这种方法适用于几乎所有的廉价数据(cheap data，容易获得的，获得的代价很低的数据)。你可能会反驳我说如果每次都重新去取数据，如：每次都连接数据库去取得对应的数据可能会比将数据存储在ViewState中代价更高，但是我不这样认为。当前的数据库管理系统(DBMS, 如SQL Server)已经相当的成熟，它们往往具有良好的缓存机制，如果配置得当的话执行的效率也非常高。(译者：我也有这样的经验，我曾经比较两种处理数据的方式，其中一种是先取得一个大范围的数据，然后在代码中通过循环的方式将其中不符合条件的数据过滤掉；另外一种方式是直接通过SQL语句在数据库中进行数据筛选，然后将符合条件的数据进行返回。根据页面显示的速度来判断，后者的执行效率远远高于前者。)其实想想到底是将一堆无用的数据通过56kbps的速度和千