ASP.Net ViewState的实现
2006-09-11 22:39
309 查看
ViewState 的工作原理
ViewState是一种机制，ASP.NET 使用这种机制来跟踪服务器控件状态值，否则这些值将不作为 HTTP 窗体的一部分而回传。例如，由 Label 控件显示的文本默认情况下就保存在 ViewState 中。作为开发人员，您可以绑定数据，或在首次加载该页面时仅对 Label 编程设置一次，在后续的回传中，该标签文本将自动从 ViewState 中重新填充。因此，除了可以减少繁琐的工作和代码外，ViewState 通常还可以减少数据库的往返次数。
ViewState 确实没有什么神秘之处，它是由 ASP.NET 页面框架管理的一个隐藏的窗体字段。当 ASP.NET 执行某个页面时，该页面上的 ViewState 值和所有控件将被收集并格式化成一个编码字符串，然后被分配给隐藏窗体字段的值属性（即 ）。由于隐藏窗体字段是发送到客户端的页面的一部分，所以 ViewState 值被临时存储在客户端的浏览器中。如果客户端选择将该页面回传给服务器，则 ViewState 字符串也将被回传。在上面的图 2 中可以看到 ViewState 窗体字段及其回传的值。
回传后，ASP.NET 页面框架将解析 ViewState 字符串，并为该页面和各个控件填充 ViewState 属性。然后，控件再使用 ViewState 数据将自己重新恢复为以前的状态。
关于 ViewState 还有三个值得注意的小问题。
如果要使用 ViewState，则在 ASPX 页面中必须有一个服务器端窗体标记 (
)。窗体字段是必需的，这样包含 ViewState 信息的隐藏字段才能回传给服务器。而且，该窗体还必须是服务器端的窗体，这样在服务器上执行该页面时，ASP.NET 页面框架才能添加隐藏的字段。
页面本身将 20 字节左右的信息保存在 ViewState 中，用于在回传时将 PostBack 数据和 ViewState 值分发给正确的控件。因此，即使该页面或应用程序禁用了 ViewState，仍可以在 ViewState 中看到少量的剩余字节。
在页面不回传的情况下，可以通过省略服务器端的
标记来去除页面中的 ViewState。
充分利用 ViewState
ViewState 为跨回传跟踪控件的状态提供了一条神奇的途径，因为它不使用服务器资源、不会超时，并且适用于任何浏览器。如果您要编写控件，那么肯定需要了解如何在控件中维护状态（英文）。
开发人员在编写页面时同样可以按照几乎相同的方式来利用 ViewState，只是有时页面会包含不由控件存储的 UI 状态值。您可以跟踪 ViewState 中的值，使用的编程语法与会话和高速缓存的语法类似：
请看下面的示例：要在 Web 页上显示一个项目列表，而每个用户需要不同的列表排序。项目列表是静态的，因此可以将这些页面绑定到相同的缓存数据集，而排序顺序只是用户特定的 UI 状态的一小部分。ViewState 非常适合于存储这种类型的值。
ViewState是.Net中提出的状态保存的一种新途径（实际上也是老瓶装新酒）；我们知道，传统的Web程序保存状态的方式有这样几种：
1、Application 这是Web应用程序生命期中的全局保存区，保存在Application中的数据是全局有效的；在Asp.Net中，有一个应用程序池，其中保存了数个（或数十个）应用程序实例，每一次请求都会从池中取一个实例来处理请求，在请求完毕之前，这个实例不会接受其他请求；这就出现一个问题，同一时间可能存在多个应用程序，也就是多个线程，这些线程都存在访问Application的可能，所以在对Application中的对象进行处理的时候需要考虑线程同步的问题；实际上Application对象内部实现了一个线程锁，调用它本身的Add、Remove等方法的时候会自动调用加锁和解锁的操作，但是出于性能考虑，对于直接通过索引器或其他方式得到其中的对象并进行操作的过程，Application并没有自动处理线程同步，需要利用下列类似的代码来处理：
Application.Lock();
((int)Application["Count"])++;
Application.Unlock();
值得注意的是，调用了Lock之后，如果没有显示的调用Unlock，那么在这个请求结束的时候，Application对象会自动解锁，这样防止了造成死锁的问题，但是为了代码的健壮性，调用完Lock并且修改完毕应该立即的调用Unlock方法。
Application对象本质上就是一个Hash表，按照键值存放了对象，由于对象是全局并且存放在服务器，并且存在多线程同时访问，所以，Application里面存放的应该是访问较多，修改较少并且是全局至少大部分功能会使用的数据，例如计数器或者数据库连接串等。
2、Session 在Asp.Net内部，有一个StateApplication来管理Session，实际上就是一个辅助进程，处理Session到期、创建的特殊请求，在收到每一次请求的时候，辅助进程就会调用状态服务器（可以通过Web.config设置不同的状态服务器）来获取Session，如果没有对应该SessionId的Session，则会新建一个，然后绑定到上下文中（HttpContext）；与Asp不同的是，Session的状态服务器有多种，目前在Asp.Net内部实现了三种：
1) InProcStateClientManager 这是传统的Session保存方式，但是还是有些细微差别
2) SqlStateClientManager 这是将Session保存到数据库方式
3) OutOfProcStateClientManager 这是将Session保存到进程外的方式
Asp.Net的Session机制有一个特点，就是处理Session的辅助进程与保存Session的状态服务器是分开的，按照MSDN的说法，有下列好处：
“因为用于会话状态的内存不在 ASP.NET 辅助进程中，所以可以实现从应用程序故障的恢复。”
“因为所有状态与辅助进程不存储在一起，您可以干净地跨多个进程对应用程序进行分区。这种分区可以显著地提高多个进程的计算机上应用程序的可用性和可缩放性。”
“因为所有状态与辅助进程不存储在一起，所以您可以跨运行于多个计算机上的多个辅助进程对应用程序进行分区。”
Asp.Net的Session机制个人观点，感觉灵活性比较好，内部实现也比较巧妙，但是实际上因为没有做过多的测试，所以应用上会不会像它说的那么美好，不敢打包票。有机会，我会单独写篇文章来深入的探讨Asp.Net 内部的Session机制。
3、Cookie 这个没甚么好说，实际上Asp.Net与Asp的Cookie没甚么分别，也许这项技术毁誉参半，而且比较依赖客户机实现，MS也没什么改进的。
4、ViewState 这是我们今天重点讨论的；实际上ViewState并不神秘，就是一个Hidden字段，但是它是服务器控件状态保存的基础；不熟悉的朋友可以用IE查看Html源码，找到一个名为"__VIEWSTATE"的Hidden字段，其中有一大堆乱七八糟的字符，这就是页面的ViewState。
做过Web程序的人可能都有这种痛苦的体会，有时候为了处理页面上面比较复杂的功能，常常会加很多Hidden，然后在服务器端用一大堆判断来分析目前的状态，写起来烦人，写完了代码更是难看；实际上，ViewState就是帮我们系统的实现了保存控件状态的功能，服务器端控件能够在多次请求间保存状态也全靠它。
好，介绍就到这里，今天我们不是讨论ViewState的使用，而是从内部来探探这个东西的本质。
我们首先建一个测试的页面：
<%@ Page language="c#" Codebehind="ViewStateTest.aspx.cs" AutoEventWireup="false" Inherits="CsdnTest.ViewStateTest" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
<html>
<head>
<title>ViewStateTest</title>
<meta name="GENERATOR" Content="Microsoft Visual Studio 7.0">
<meta name="CODE_LANGUAGE" Content="C#">
<meta name="vs_defaultClientScript" content="JavaScript">
<meta name="vs_targetSchema" content="http://schemas.microsoft.com/intellisense/ie5">
</head>
<body>
<form id="ViewStateTest" method="post" runat="server">
<asp:Button ID="btnPostBack" Runat="server" Text="Post Back" Width="85px"></asp:Button>
<br/>
<asp:CheckBox ID="chkTest" Runat="server" Text="This is a check box"></asp:CheckBox>
</form>
</body>
</html>
这是用Vs.Net设计出来的一个简单的页面，里面包含了一个服务器端的按钮和一个CheckBox，然后我们在服务器端响应按钮的事件：
private void btnPostBack_Click(object sender, System.EventArgs e)
{
[1] Response.Write( "ViewState :"+Request.Params["__VIEWSTATE"]+"<br/>" );
[2] string decodeValue = Encoding.UTF8.GetString( Convert.FromBase64String( Request.Params["__VIEWSTATE"] ) );
[3] Response.Write( "ViewState decode :"+decodeValue+"<br/>" );
[4] object viewstate = (new LosFormatter()).Deserialize( Request.Params["__VIEWSTATE"] );
[5] Response.Write( "ViewState Object :"+viewstate.GetType().Name );
}
为了方便看，我加上了行号；第一行我们把ViewState的值打出来，第二行是什么呢？实际上ViewState保存到客户端的一串字符串就是内部的ViewState通过某种方式序列化之后再经过Base64编码得来的，所以我们把Base64编码的字符串反编码一次再打出来；至于第四行，我先不说，先看执行结果：
运行之后，页面上什么都没有，除了按钮和CheckBox（废话 ：）），我们点击按钮，然后结果如下：
[A] ViewState :dDwxMjU2MDI5MTA3OztsPGNoa1Rlc3Q7Pj6Gg0Qzm+7gacYWcy0hnRCT9toOdA==
ViewState decode:t<1256029107;;l>D3i s-! t
[C] ViewState Object :Triplet
然后我们来分析这个结果，A中显示的就是ViewState传到客户端的值，B中显示的是通过Base64反编码之后的值，从这里面好像还是看不出什么，C中出现了一个:Triplet ？这是什么呢，我们回到上面的代码：
object viewstate = (new LosFormatter()).Deserialize( Request.Params["__VIEWSTATE"] );
注意我们使用了一个LosFormatter类，实际上这个类就是Asp.Net内部为ViewState提供序列化的类，它有两个方法，一个是Serialize，就是序列化一个对象，一个是Deserialize，是反序列化，我们这里使用了反序列化的方法来把ViewState直接反序列化成一个对象，然后把这个对象的类型打出来，这个对象就是:Triplet类型，实际上Asp.Net中页面保存的ViewState就是这个类型，我们先分析一下LosFormater，再来细说.
我们再回来看打出来的结果B：t<1256029107;;l>D3i s-!
t，实际上通过查看LosFormatter反编译后的代码，大致上可以看出它序列化的方式是很简单的，就是判断要序列化对象的类型，如果不是直接序列化的类型，则把它的类型记录下来，然后在递归序列化它的属性，我们看B中的"t"就是表示Triplet这个类型，这个类型有三个属性，这三个属性包含在"<"和">"之间，用";"分割，而最后面的D3i s-!
t据我分析应该是一个防止ViewState被改变的Hash值，这个不是很确定，因为反编译的代码实在是很难看，我只是了解之后就没仔细看了。
我们刚刚分析出来Page中的ViewState反序列化之后是Triplet这个类型，实际上这个类在MSDN中就查得到，它就是一个包含了三个对象的对象，说简单点，它就是一个能放三个箱子的大箱子（好像还是说的比较糊涂，呵呵），它有三个属性：First、Second、Thrid ：），分别代表三个对象。
对应到Page当中，First是Page.GetTypeHashCode()的返回值，这个方法是System.Web.UI.Page定义的一个保护的虚拟方法，返回一个整型，由Aspx文件生成的类来实现的，因为这个类是有Asp.Net负责在运行期生成源代码并编译，它会计算出一个大常量作为返回值，这个返回值在整个Web应用程序所有的Page中是唯一的。（提一句题外话，Asp.Net自动产生的源代码可以到 系统盘:/WINDOWS/Microsoft.NET/Framework/v1.0.3705/Temporary ASP.NET Files下面去找），这个唯一的Hash值是为了在ViewState中产生一个标记，使这个ViewState只适用与对应的页面。
Second则是通Control.SaveViewStateRecursive方法递归保存页面控件树的ViewState返回的对象，也就是真正的ViewState的数据。
Third中保存的是当前页面需要PostBack的控件名的列表。
分析了页面的ViewState的构成，我们再来看Control的ViewState的实现。ViewState是System.Web.UI.Control类实现的一个属性，这个属性的类型是System.Web.UI.StateBag，这个类就包含了ViewState数据结构的实现，实际上它的内部也就是个Hash表，通过Key值来保存和检索数据。
那么服务器控件是怎么实现保存状态的呢？
我们知道，所有的服务器控件都是从System.Web.UI.Control派生的，所以都拥有ViewState这个属性，在Control内部，定义了两个Protected的虚拟方法：
protected virtual object SaveViewState()
和
protected virtual void LoadViewState(object savedState)
这两个方法是给子控件派生用来保存和读取自己的ViewState的，比如我们有一个自己写的控件，往ViewState中保存了一个字符串，那么我们的方法大致像这样：
protected virtual object SaveViewState()
{
object[] states = new object[2];
states[0] = base.SaveViewState(); //记得保存父控件的ViewState
states[1] = "Hello,I'm timmy!"; //这里保存我们自己的
return states; //返回重新包装后的保存对象
}
获取的时候：
protected override void LoadViewState(object savedState) //这里的savedState就是我们Save的时候return 的object数组
{
object[] states = (object[])savedState;
base.LoadViewState( states[0] ); //把父类的数据给他自己去解析
string myData = (string)states[1]; //获取我们自己的数据
}
我们可以按照自己的方式来保存，不一定非要像上面这样用数组，实际上我们可以用任何支持序列化的对象都可以，父类并不关心子类如何保存，我们只要在Save和Load的时候使用同样的方式，并且把正确的数据传递给父类方法就可以了。
另外，还有一个问题就是我们使用的Control的ViewState是Key-Value这样的键值对，那它是怎么保存的呢？
实际上很简单，System.UI.Web下面有一个类叫Pair，呵呵，这个和Triplet差不多，只是它里面只有两个对象。StateBag保存的时候，First会存放所有Key值的数组，Second则存放所有Value的数组。
到现在，我们了解了ViewState是如何序列化并且保存到客户端，也了解了控件怎么保存自己的ViewState，那么这二者是怎么结合的呢？
也就是整个页面的控件树的ViewState是怎么保存和读取的呢？
在Control内部有两个internal的方法：
internal object SaveViewStateRecursive()；
internal void LoadRecursive()；
这两个方法由System.Web.UI.Page来调用，Page在Render结束后就会调用SavePageViewState方法，SavePageViewState方法会调用Control的SaveViewStateRecursive()方法，这个方法就是通过递归调用每一个Control.Controls的SaveViewStateRecursive方法来保存控件树中所有控件的ViewState。到这里，可能聪明的朋友要问了，既然SaveViewStateRecursive是递归调用保存的方法，那么我们上面写的SaveViewState()方法又有什么用呢？
我们知道，Control.Controls可能会有很多个，而且我们的SaveViewState()只保存了当前控件的数据，而没有记录控件树的结构，那么如果我们递归SaveViewState()方法来保存数据的话，那么控件树的结构就会丢失，那么Load的时候就没办法还原了，实际上在SaveViewStateRecursive方法中大致的代码是这样：
[1] 获取控件自己的ViewState（调用SaveViewState方法）
[2] 循环子控件
{
定义两个动态数组，一个保存控件的索引，一个保存递归调用子控件SaveViewStateRecursive方法返回的值
}
[3] 定义一个Triplet（呵呵，这个东西又出现了）
[4] First保存本控件的ViewState
[5] Second保存子控件的索引
[6] Third保存递归子控件SaveViewStateRecursive方法的返回值
[7] 返回Triplet
这样就保存了整个控件树的ViewState和控件树的结构
Load的方式与Save差不多，只是Load的时候会从savedState中获取子控件的索引来依次递归子控件的LoadRecursive()方法，这样才能保证正确的把保存的数据传给子控件。
到这里，ViewState的实现我们大致了解了一下，最后得出一些结论：
1、ViewState是存放在客户端，因此会减轻服务器的负担，是一种比较好的保存数据的方式。
2、因为ViewState本身的限制，只能保存可以序列化的对象，而且最好不要放太多东西，能省则省，以免在减慢传输的速度，以及加重服务器解析的负担。
3、我们通过很简单的方式就可以把ViewState里面的值获取出来，我们上面讨论了一些，虽然没有把解析的代码写出来，但是利用LosFormatter可以得到ViewState反序列化后的对象，那么要解析出来简直是易如反掌；所以ViewState在安全性上面还是比较差，建议不要
存放比较机密和敏感的信息，尽管ViewState可以加密，但是由于ViewState要保存在客户端，天生就有安全性的隐患。
4、实际从技术角度，ViewState没有任何新意，但是结合服务器控件的设计还是很巧妙的。
最后，以我个人的观点，我觉得ViewState的出现很大程度上减轻了程序员的负担，但是要看清的是ViewState的本质，合理的应用它。
匆忙写就难免有很多问题，还希望大家多提意见，不足之处请多指教！
[b]ASP.NET中的ViewState
ViewState是ASP.NET中用来保存WEB控件回传时状态值一种机制。在WEB窗体(FORM)的设置为runat="server",这个窗体(FORM)会被附加一个隐藏的属性_VIEWSTATE。_VIEWSTATE中存放了所有控件在ViewState中的状态值。
ViewState是类Control中的一个域，其他所有控件通过继承Control来获得了ViewState功能。它的类型是system.Web.UI.StateBag，一个名称/值的对象集合。
当请求某个页面时，ASP.NET把所有控件的状态序列化成一个字符串，然后做为窗体的隐藏属性送到客户端。当客户端把页面回传时，ASP.NET分析回传的窗体属性，并赋给控件对应的值。当然这些全部是由ASP.NET负责的，对用户来说是透明的。
使用ViewState的条件
如果要使用 ViewState，则在 ASPX 页面中必须有一个服务器端窗体标记 (<form runat=server>)。窗体字段是必需的，这样包含 ViewState 信息的隐藏字段才能回传给服务器。而且，该窗体还必须是服务器端的窗体，这样在服务器上执行该页面时，ASP.NET 页面框架才能添加隐藏的字段。
Page 的 EnableViewState 属性值为 true。
控件的 EnableViewState 属性值为 true。
页面本身将 20 字节左右的信息保存在 ViewState 中，用于在回传时将 PostBack 数据和 ViewState 值分发给正确的控件。因此，即使该页面或应用程序禁用了 ViewState，仍可以在 ViewState 中看到少量的剩余字节。
设置ViewState
ViewState可以在控件，页，程序，全局配置中设置。缺省情况下 EnableViewState 为 true 。如果要禁止所有页面 ViewState 功能，可以在程序配置中把 EnableViewState 设为 false 。
在控件中：
<asp:DataGrid EnableViewState="false"%>
或
DataGrid1.EnableViewState = false;
在页中：
<%@ Page EnableViewState="false" %>
或
Page.EnableViewState = false;
在程序中：
在web.config中加入 <pages enableViewState="false" />
在全局配置：
在machine.config中修改 <pages enableViewState="false" />
EnableViewState优先级别：
全局配置 < 程序 < 页 < 控件
注意：下列服务器控件不能禁止ViewState
Textbox
Checkbox
Checkbox List
RadioButtonList
上面控件的状态通过IPostBackEventHandler 和 IPostBackDataHandler接口处理，而不是ViewState的机制，所以EnableViewState没有效果。
ViewState对象
在页面回传间通信，ASP中一般利用窗体的属性和 session 来存放数据，在 ASP.NET 中也可以使用 ViewState 对象来做同样的处理。
在ViewState存放数据：
ViewState[key] = value;
或
ViewState.Add(key, value);
取出数据：
TempStr = ViewState[key];
key不存在时返回空。
不能通过ViewState对象来访问控件的值。
动态建立控件的ViewState:
当需要动态地建立一个服务器控件，如下建立了一个 RadioButton 控件并加入到窗体控件集合中：
RadioButton rb = new RadioButton();
Page.Controls[1].Controls.Add(pc);
上面的代码增加一个控件到控件集合末，同样也可以插入到已有控件中的任何位置。
RadioButton rb = new RadioButton();
Page.Controls[1].Controls.AddAt(1,pc);
通常，这些动态生成的控件的状态也需要生成到 ViewState 中去，但这个功能并没有完全实现，特别是生成的控件插入到已有的控件中时。
当动态生成控件和已有控件并存时 ViewState 的结果是不可预料的。在页面回传时，首先非动态生成的控件在ASPX页中被生成，并在 Page_Init
和 Page_Load 事件中读取 ViewState。当页面的控件读取 ViewState 的值时，那些动态生成的控件却还没有被生成，所以当动态生成的控件被
生成时，页面就会省略掉ViewState或者以剩下或许错误的 ViewState 来填充控件。
所以，当需要插一个动态生成的控件到已有控件中去时，最好把这个控件的 ViewState 通过EnableViewState禁止掉。
提醒：
1. 当存在页面回传时，不需要维持控件的值就要把 ViewState 禁止。
2. ViewState的索引是大小写敏感的。
3. ViewState不是跨页面的。
4. 为了能包存在 ViewState 中，对象必须是可流化或者定义了 TypeConverter。
5. 控件 TextBox 的 TextMode 属性设置为 Password时，它的状态将不会被保存在 ViewState 中，这应该是出于安全性的考虑。
6. 在页面 没有回传 或 重定向 或 在回传中转到(transfer)其他页面 时不要使用 ViewState。
7. 在动态建立控件时要小心它的 ViewState。
8. 当禁止一个程序的 ViewState 时，这个程序的所有页面的 ViewState 也被禁止了。
9. 只有当页面回传自身时 ViewState 才是持续的。
ViewState是一种机制，ASP.NET 使用这种机制来跟踪服务器控件状态值，否则这些值将不作为 HTTP 窗体的一部分而回传。例如，由 Label 控件显示的文本默认情况下就保存在 ViewState 中。作为开发人员，您可以绑定数据，或在首次加载该页面时仅对 Label 编程设置一次，在后续的回传中，该标签文本将自动从 ViewState 中重新填充。因此，除了可以减少繁琐的工作和代码外，ViewState 通常还可以减少数据库的往返次数。
ViewState 确实没有什么神秘之处，它是由 ASP.NET 页面框架管理的一个隐藏的窗体字段。当 ASP.NET 执行某个页面时，该页面上的 ViewState 值和所有控件将被收集并格式化成一个编码字符串，然后被分配给隐藏窗体字段的值属性（即 ）。由于隐藏窗体字段是发送到客户端的页面的一部分，所以 ViewState 值被临时存储在客户端的浏览器中。如果客户端选择将该页面回传给服务器，则 ViewState 字符串也将被回传。在上面的图 2 中可以看到 ViewState 窗体字段及其回传的值。
回传后，ASP.NET 页面框架将解析 ViewState 字符串，并为该页面和各个控件填充 ViewState 属性。然后，控件再使用 ViewState 数据将自己重新恢复为以前的状态。
关于 ViewState 还有三个值得注意的小问题。
如果要使用 ViewState，则在 ASPX 页面中必须有一个服务器端窗体标记 (
)。窗体字段是必需的，这样包含 ViewState 信息的隐藏字段才能回传给服务器。而且，该窗体还必须是服务器端的窗体，这样在服务器上执行该页面时，ASP.NET 页面框架才能添加隐藏的字段。
页面本身将 20 字节左右的信息保存在 ViewState 中，用于在回传时将 PostBack 数据和 ViewState 值分发给正确的控件。因此，即使该页面或应用程序禁用了 ViewState，仍可以在 ViewState 中看到少量的剩余字节。
在页面不回传的情况下，可以通过省略服务器端的
标记来去除页面中的 ViewState。
充分利用 ViewState
ViewState 为跨回传跟踪控件的状态提供了一条神奇的途径，因为它不使用服务器资源、不会超时，并且适用于任何浏览器。如果您要编写控件，那么肯定需要了解如何在控件中维护状态（英文）。
开发人员在编写页面时同样可以按照几乎相同的方式来利用 ViewState，只是有时页面会包含不由控件存储的 UI 状态值。您可以跟踪 ViewState 中的值，使用的编程语法与会话和高速缓存的语法类似：
请看下面的示例：要在 Web 页上显示一个项目列表，而每个用户需要不同的列表排序。项目列表是静态的，因此可以将这些页面绑定到相同的缓存数据集，而排序顺序只是用户特定的 UI 状态的一小部分。ViewState 非常适合于存储这种类型的值。
ViewState是.Net中提出的状态保存的一种新途径（实际上也是老瓶装新酒）；我们知道，传统的Web程序保存状态的方式有这样几种：
1、Application 这是Web应用程序生命期中的全局保存区，保存在Application中的数据是全局有效的；在Asp.Net中，有一个应用程序池，其中保存了数个（或数十个）应用程序实例，每一次请求都会从池中取一个实例来处理请求，在请求完毕之前，这个实例不会接受其他请求；这就出现一个问题，同一时间可能存在多个应用程序，也就是多个线程，这些线程都存在访问Application的可能，所以在对Application中的对象进行处理的时候需要考虑线程同步的问题；实际上Application对象内部实现了一个线程锁，调用它本身的Add、Remove等方法的时候会自动调用加锁和解锁的操作，但是出于性能考虑，对于直接通过索引器或其他方式得到其中的对象并进行操作的过程，Application并没有自动处理线程同步，需要利用下列类似的代码来处理：
Application.Lock();
((int)Application["Count"])++;
Application.Unlock();
值得注意的是，调用了Lock之后，如果没有显示的调用Unlock，那么在这个请求结束的时候，Application对象会自动解锁，这样防止了造成死锁的问题，但是为了代码的健壮性，调用完Lock并且修改完毕应该立即的调用Unlock方法。
Application对象本质上就是一个Hash表，按照键值存放了对象，由于对象是全局并且存放在服务器，并且存在多线程同时访问，所以，Application里面存放的应该是访问较多，修改较少并且是全局至少大部分功能会使用的数据，例如计数器或者数据库连接串等。
2、Session 在Asp.Net内部，有一个StateApplication来管理Session，实际上就是一个辅助进程，处理Session到期、创建的特殊请求，在收到每一次请求的时候，辅助进程就会调用状态服务器（可以通过Web.config设置不同的状态服务器）来获取Session，如果没有对应该SessionId的Session，则会新建一个，然后绑定到上下文中（HttpContext）；与Asp不同的是，Session的状态服务器有多种，目前在Asp.Net内部实现了三种：
1) InProcStateClientManager 这是传统的Session保存方式，但是还是有些细微差别
2) SqlStateClientManager 这是将Session保存到数据库方式
3) OutOfProcStateClientManager 这是将Session保存到进程外的方式
Asp.Net的Session机制有一个特点，就是处理Session的辅助进程与保存Session的状态服务器是分开的，按照MSDN的说法，有下列好处：
“因为用于会话状态的内存不在 ASP.NET 辅助进程中，所以可以实现从应用程序故障的恢复。”
“因为所有状态与辅助进程不存储在一起，您可以干净地跨多个进程对应用程序进行分区。这种分区可以显著地提高多个进程的计算机上应用程序的可用性和可缩放性。”
“因为所有状态与辅助进程不存储在一起，所以您可以跨运行于多个计算机上的多个辅助进程对应用程序进行分区。”
Asp.Net的Session机制个人观点，感觉灵活性比较好，内部实现也比较巧妙，但是实际上因为没有做过多的测试，所以应用上会不会像它说的那么美好，不敢打包票。有机会，我会单独写篇文章来深入的探讨Asp.Net 内部的Session机制。
3、Cookie 这个没甚么好说，实际上Asp.Net与Asp的Cookie没甚么分别，也许这项技术毁誉参半，而且比较依赖客户机实现，MS也没什么改进的。
4、ViewState 这是我们今天重点讨论的；实际上ViewState并不神秘，就是一个Hidden字段，但是它是服务器控件状态保存的基础；不熟悉的朋友可以用IE查看Html源码，找到一个名为"__VIEWSTATE"的Hidden字段，其中有一大堆乱七八糟的字符，这就是页面的ViewState。
做过Web程序的人可能都有这种痛苦的体会，有时候为了处理页面上面比较复杂的功能，常常会加很多Hidden，然后在服务器端用一大堆判断来分析目前的状态，写起来烦人，写完了代码更是难看；实际上，ViewState就是帮我们系统的实现了保存控件状态的功能，服务器端控件能够在多次请求间保存状态也全靠它。
好，介绍就到这里，今天我们不是讨论ViewState的使用，而是从内部来探探这个东西的本质。
我们首先建一个测试的页面：
<%@ Page language="c#" Codebehind="ViewStateTest.aspx.cs" AutoEventWireup="false" Inherits="CsdnTest.ViewStateTest" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
<html>
<head>
<title>ViewStateTest</title>
<meta name="GENERATOR" Content="Microsoft Visual Studio 7.0">
<meta name="CODE_LANGUAGE" Content="C#">
<meta name="vs_defaultClientScript" content="JavaScript">
<meta name="vs_targetSchema" content="http://schemas.microsoft.com/intellisense/ie5">
</head>
<body>
<form id="ViewStateTest" method="post" runat="server">
<asp:Button ID="btnPostBack" Runat="server" Text="Post Back" Width="85px"></asp:Button>
<br/>
<asp:CheckBox ID="chkTest" Runat="server" Text="This is a check box"></asp:CheckBox>
</form>
</body>
</html>
这是用Vs.Net设计出来的一个简单的页面，里面包含了一个服务器端的按钮和一个CheckBox，然后我们在服务器端响应按钮的事件：
private void btnPostBack_Click(object sender, System.EventArgs e)
{
[1] Response.Write( "ViewState :"+Request.Params["__VIEWSTATE"]+"<br/>" );
[2] string decodeValue = Encoding.UTF8.GetString( Convert.FromBase64String( Request.Params["__VIEWSTATE"] ) );
[3] Response.Write( "ViewState decode :"+decodeValue+"<br/>" );
[4] object viewstate = (new LosFormatter()).Deserialize( Request.Params["__VIEWSTATE"] );
[5] Response.Write( "ViewState Object :"+viewstate.GetType().Name );
}
为了方便看，我加上了行号；第一行我们把ViewState的值打出来，第二行是什么呢？实际上ViewState保存到客户端的一串字符串就是内部的ViewState通过某种方式序列化之后再经过Base64编码得来的，所以我们把Base64编码的字符串反编码一次再打出来；至于第四行，我先不说，先看执行结果：
运行之后，页面上什么都没有，除了按钮和CheckBox（废话 ：）），我们点击按钮，然后结果如下：
[A] ViewState :dDwxMjU2MDI5MTA3OztsPGNoa1Rlc3Q7Pj6Gg0Qzm+7gacYWcy0hnRCT9toOdA==
ViewState decode:t<1256029107;;l>D3i s-! t
[C] ViewState Object :Triplet
然后我们来分析这个结果，A中显示的就是ViewState传到客户端的值，B中显示的是通过Base64反编码之后的值，从这里面好像还是看不出什么，C中出现了一个:Triplet ？这是什么呢，我们回到上面的代码：
object viewstate = (new LosFormatter()).Deserialize( Request.Params["__VIEWSTATE"] );
注意我们使用了一个LosFormatter类，实际上这个类就是Asp.Net内部为ViewState提供序列化的类，它有两个方法，一个是Serialize，就是序列化一个对象，一个是Deserialize，是反序列化，我们这里使用了反序列化的方法来把ViewState直接反序列化成一个对象，然后把这个对象的类型打出来，这个对象就是:Triplet类型，实际上Asp.Net中页面保存的ViewState就是这个类型，我们先分析一下LosFormater，再来细说.
我们再回来看打出来的结果B：t<1256029107;;l>D3i s-!
t，实际上通过查看LosFormatter反编译后的代码，大致上可以看出它序列化的方式是很简单的，就是判断要序列化对象的类型，如果不是直接序列化的类型，则把它的类型记录下来，然后在递归序列化它的属性，我们看B中的"t"就是表示Triplet这个类型，这个类型有三个属性，这三个属性包含在"<"和">"之间，用";"分割，而最后面的D3i s-!
t据我分析应该是一个防止ViewState被改变的Hash值，这个不是很确定，因为反编译的代码实在是很难看，我只是了解之后就没仔细看了。
我们刚刚分析出来Page中的ViewState反序列化之后是Triplet这个类型，实际上这个类在MSDN中就查得到，它就是一个包含了三个对象的对象，说简单点，它就是一个能放三个箱子的大箱子（好像还是说的比较糊涂，呵呵），它有三个属性：First、Second、Thrid ：），分别代表三个对象。
对应到Page当中，First是Page.GetTypeHashCode()的返回值，这个方法是System.Web.UI.Page定义的一个保护的虚拟方法，返回一个整型，由Aspx文件生成的类来实现的，因为这个类是有Asp.Net负责在运行期生成源代码并编译，它会计算出一个大常量作为返回值，这个返回值在整个Web应用程序所有的Page中是唯一的。（提一句题外话，Asp.Net自动产生的源代码可以到 系统盘:/WINDOWS/Microsoft.NET/Framework/v1.0.3705/Temporary ASP.NET Files下面去找），这个唯一的Hash值是为了在ViewState中产生一个标记，使这个ViewState只适用与对应的页面。
Second则是通Control.SaveViewStateRecursive方法递归保存页面控件树的ViewState返回的对象，也就是真正的ViewState的数据。
Third中保存的是当前页面需要PostBack的控件名的列表。
分析了页面的ViewState的构成，我们再来看Control的ViewState的实现。ViewState是System.Web.UI.Control类实现的一个属性，这个属性的类型是System.Web.UI.StateBag，这个类就包含了ViewState数据结构的实现，实际上它的内部也就是个Hash表，通过Key值来保存和检索数据。
那么服务器控件是怎么实现保存状态的呢？
我们知道，所有的服务器控件都是从System.Web.UI.Control派生的，所以都拥有ViewState这个属性，在Control内部，定义了两个Protected的虚拟方法：
protected virtual object SaveViewState()
和
protected virtual void LoadViewState(object savedState)
这两个方法是给子控件派生用来保存和读取自己的ViewState的，比如我们有一个自己写的控件，往ViewState中保存了一个字符串，那么我们的方法大致像这样：
protected virtual object SaveViewState()
{
object[] states = new object[2];
states[0] = base.SaveViewState(); //记得保存父控件的ViewState
states[1] = "Hello,I'm timmy!"; //这里保存我们自己的
return states; //返回重新包装后的保存对象
}
获取的时候：
protected override void LoadViewState(object savedState) //这里的savedState就是我们Save的时候return 的object数组
{
object[] states = (object[])savedState;
base.LoadViewState( states[0] ); //把父类的数据给他自己去解析
string myData = (string)states[1]; //获取我们自己的数据
}
我们可以按照自己的方式来保存，不一定非要像上面这样用数组，实际上我们可以用任何支持序列化的对象都可以，父类并不关心子类如何保存，我们只要在Save和Load的时候使用同样的方式，并且把正确的数据传递给父类方法就可以了。
另外，还有一个问题就是我们使用的Control的ViewState是Key-Value这样的键值对，那它是怎么保存的呢？
实际上很简单，System.UI.Web下面有一个类叫Pair，呵呵，这个和Triplet差不多，只是它里面只有两个对象。StateBag保存的时候，First会存放所有Key值的数组，Second则存放所有Value的数组。
到现在，我们了解了ViewState是如何序列化并且保存到客户端，也了解了控件怎么保存自己的ViewState，那么这二者是怎么结合的呢？
也就是整个页面的控件树的ViewState是怎么保存和读取的呢？
在Control内部有两个internal的方法：
internal object SaveViewStateRecursive()；
internal void LoadRecursive()；
这两个方法由System.Web.UI.Page来调用，Page在Render结束后就会调用SavePageViewState方法，SavePageViewState方法会调用Control的SaveViewStateRecursive()方法，这个方法就是通过递归调用每一个Control.Controls的SaveViewStateRecursive方法来保存控件树中所有控件的ViewState。到这里，可能聪明的朋友要问了，既然SaveViewStateRecursive是递归调用保存的方法，那么我们上面写的SaveViewState()方法又有什么用呢？
我们知道，Control.Controls可能会有很多个，而且我们的SaveViewState()只保存了当前控件的数据，而没有记录控件树的结构，那么如果我们递归SaveViewState()方法来保存数据的话，那么控件树的结构就会丢失，那么Load的时候就没办法还原了，实际上在SaveViewStateRecursive方法中大致的代码是这样：
[1] 获取控件自己的ViewState（调用SaveViewState方法）
[2] 循环子控件
{
定义两个动态数组，一个保存控件的索引，一个保存递归调用子控件SaveViewStateRecursive方法返回的值
}
[3] 定义一个Triplet（呵呵，这个东西又出现了）
[4] First保存本控件的ViewState
[5] Second保存子控件的索引
[6] Third保存递归子控件SaveViewStateRecursive方法的返回值
[7] 返回Triplet
这样就保存了整个控件树的ViewState和控件树的结构
Load的方式与Save差不多，只是Load的时候会从savedState中获取子控件的索引来依次递归子控件的LoadRecursive()方法，这样才能保证正确的把保存的数据传给子控件。
到这里，ViewState的实现我们大致了解了一下，最后得出一些结论：
1、ViewState是存放在客户端，因此会减轻服务器的负担，是一种比较好的保存数据的方式。
2、因为ViewState本身的限制，只能保存可以序列化的对象，而且最好不要放太多东西，能省则省，以免在减慢传输的速度，以及加重服务器解析的负担。
3、我们通过很简单的方式就可以把ViewState里面的值获取出来，我们上面讨论了一些，虽然没有把解析的代码写出来，但是利用LosFormatter可以得到ViewState反序列化后的对象，那么要解析出来简直是易如反掌；所以ViewState在安全性上面还是比较差，建议不要
存放比较机密和敏感的信息，尽管ViewState可以加密，但是由于ViewState要保存在客户端，天生就有安全性的隐患。
4、实际从技术角度，ViewState没有任何新意，但是结合服务器控件的设计还是很巧妙的。
最后，以我个人的观点，我觉得ViewState的出现很大程度上减轻了程序员的负担，但是要看清的是ViewState的本质，合理的应用它。
匆忙写就难免有很多问题，还希望大家多提意见，不足之处请多指教！
[b]ASP.NET中的ViewState
ViewState是ASP.NET中用来保存WEB控件回传时状态值一种机制。在WEB窗体(FORM)的设置为runat="server",这个窗体(FORM)会被附加一个隐藏的属性_VIEWSTATE。_VIEWSTATE中存放了所有控件在ViewState中的状态值。
ViewState是类Control中的一个域，其他所有控件通过继承Control来获得了ViewState功能。它的类型是system.Web.UI.StateBag，一个名称/值的对象集合。
当请求某个页面时，ASP.NET把所有控件的状态序列化成一个字符串，然后做为窗体的隐藏属性送到客户端。当客户端把页面回传时，ASP.NET分析回传的窗体属性，并赋给控件对应的值。当然这些全部是由ASP.NET负责的，对用户来说是透明的。
使用ViewState的条件
如果要使用 ViewState，则在 ASPX 页面中必须有一个服务器端窗体标记 (<form runat=server>)。窗体字段是必需的，这样包含 ViewState 信息的隐藏字段才能回传给服务器。而且，该窗体还必须是服务器端的窗体，这样在服务器上执行该页面时，ASP.NET 页面框架才能添加隐藏的字段。
Page 的 EnableViewState 属性值为 true。
控件的 EnableViewState 属性值为 true。
页面本身将 20 字节左右的信息保存在 ViewState 中，用于在回传时将 PostBack 数据和 ViewState 值分发给正确的控件。因此，即使该页面或应用程序禁用了 ViewState，仍可以在 ViewState 中看到少量的剩余字节。
设置ViewState
ViewState可以在控件，页，程序，全局配置中设置。缺省情况下 EnableViewState 为 true 。如果要禁止所有页面 ViewState 功能，可以在程序配置中把 EnableViewState 设为 false 。
在控件中：
<asp:DataGrid EnableViewState="false"%>
或
DataGrid1.EnableViewState = false;
在页中：
<%@ Page EnableViewState="false" %>
或
Page.EnableViewState = false;
在程序中：
在web.config中加入 <pages enableViewState="false" />
在全局配置：
在machine.config中修改 <pages enableViewState="false" />
EnableViewState优先级别：
全局配置 < 程序 < 页 < 控件
注意：下列服务器控件不能禁止ViewState
Textbox
Checkbox
Checkbox List
RadioButtonList
上面控件的状态通过IPostBackEventHandler 和 IPostBackDataHandler接口处理，而不是ViewState的机制，所以EnableViewState没有效果。
ViewState对象
在页面回传间通信，ASP中一般利用窗体的属性和 session 来存放数据，在 ASP.NET 中也可以使用 ViewState 对象来做同样的处理。
在ViewState存放数据：
ViewState[key] = value;
或
ViewState.Add(key, value);
取出数据：
TempStr = ViewState[key];
key不存在时返回空。
不能通过ViewState对象来访问控件的值。
动态建立控件的ViewState:
当需要动态地建立一个服务器控件，如下建立了一个 RadioButton 控件并加入到窗体控件集合中：
RadioButton rb = new RadioButton();
Page.Controls[1].Controls.Add(pc);
上面的代码增加一个控件到控件集合末，同样也可以插入到已有控件中的任何位置。
RadioButton rb = new RadioButton();
Page.Controls[1].Controls.AddAt(1,pc);
通常，这些动态生成的控件的状态也需要生成到 ViewState 中去，但这个功能并没有完全实现，特别是生成的控件插入到已有的控件中时。
当动态生成控件和已有控件并存时 ViewState 的结果是不可预料的。在页面回传时，首先非动态生成的控件在ASPX页中被生成，并在 Page_Init
和 Page_Load 事件中读取 ViewState。当页面的控件读取 ViewState 的值时，那些动态生成的控件却还没有被生成，所以当动态生成的控件被
生成时，页面就会省略掉ViewState或者以剩下或许错误的 ViewState 来填充控件。
所以，当需要插一个动态生成的控件到已有控件中去时，最好把这个控件的 ViewState 通过EnableViewState禁止掉。
提醒：
1. 当存在页面回传时，不需要维持控件的值就要把 ViewState 禁止。
2. ViewState的索引是大小写敏感的。
3. ViewState不是跨页面的。
4. 为了能包存在 ViewState 中，对象必须是可流化或者定义了 TypeConverter。
5. 控件 TextBox 的 TextMode 属性设置为 Password时，它的状态将不会被保存在 ViewState 中，这应该是出于安全性的考虑。
6. 在页面 没有回传 或 重定向 或 在回传中转到(transfer)其他页面 时不要使用 ViewState。
7. 在动态建立控件时要小心它的 ViewState。
8. 当禁止一个程序的 ViewState 时，这个程序的所有页面的 ViewState 也被禁止了。
9. 只有当页面回传自身时 ViewState 才是持续的。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- ASP.Net ViewState的实现
- ASP.Net ViewState的实现
- ASP.Net ViewState的实现
- ASP.Net ViewState的实现
- ASP.Net ViewState的实现
- ASP.NET ViewState 实现分析(转贴)
- ASP.Net ViewState的实现
- ASP.NetViewState的实现方案
- asp.net 生成静态时的过滤viewstate的实现方法
- ASP.Net ViewState的实现内幕
- ASP.Net ViewState的实现
- ASP.NET的页面生存周期和ViewState实现机制
- asp.net 生成静态时的过滤viewstate的实现方法
- ASP.Net ViewState的实现
- ASP.Net ViewState的实现
- ASP.NET ViewState 实现分析(转)
- 用 ASP.NET 2.0 改进的 ViewState 加快网站速度
- 浅析ASP.NET应用ViewState技术
- asp.net不使用ViewState和服务器控件
- asp.net 2.0里当readonly遇上enableviewstate=false