.Session与DataSet互转换（不建议）操作方法：
Session["sss"] = ds; //将DataSet对象保存到Session中
DataSet ds = (DataSet)Session["sss"];//强制类型转换后得到保存的dataset
2.Session与ViewState的比较
|
Session |
ViewState |
|
|
占用服务器资源 |
true |
false |
|
Time out |
true |
false |
|
存储任何.net类型 |
true |
flase(只支持strings,integers,Booleans,arrays, |
|
加重html负载 |
false |
true |
session对于整个application有效，而viewstate相当于某个页面的session.
定义 viewstate
// save in ViewState
ViewState["SortOrder"] = "DESC";
// read from ViewState
string sortOrder = (string)ViewState["SortOrder"];
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机制个人观点，感觉灵活性比较好，内部实现也比较巧妙，但是实际上因为没有做过多的测试，所以应用上会不会像它说的那么美好，不敢打包票。
3.ApplicationApplication 这是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里面存放的应该是访问较多，修改较少并且是全局至少大部分功能会使用的数据，例如计数器或者数据库连接串等。
在ASP.Net中Application用法与ASP是一样的，几乎是没有什么说的，但是它多了两个特别有用的事件， Application_OnBeginRequest和Application_OnEndRequest。他们的和原来的 Application_OnStart和Application_OnEnd一样是放在global文件中的(注意这个文件在ASP中名字是 global.asa，在ASP.Net中是global.asax)。
注：这个事件，写不写On是一样的。如Application_End与Application_OnEnd是一样的
Application_OnStart是在整个ASP.Net应用首先被触发的事件，也就是在一个虚拟目录中第一个ASP.Net程序执行时触发，Application_OnEnd就正好相反，在整个应用停止时被触发（通常发生在服务器被重启/关机时)。 Application_OnRequestStart和Application_OnRequestEnd则是在每一个ASP.Net程序被请求时就发生，也就是说客户访问一次一个ASP.Net程序，这两个事件就会被触发。我们可以从下面的程序看到他的应用.我们先建立一个global.asax,内容如下：
<script language="C#" runat="server">
void Application_OnBeginRequest(Object sender, EventArgs E)
{
Response.Write("Request is Starting...<br>");
}
void Application_OnEndRequest(Object sender, EventArgs E)
{
Response.Write("Request is Ending...<br>");
}
</script>
然后将其放到本虚拟目录的根目录下,然后我们随便打开一个什么aspx文件
我们在global.asax中定义的语句Request is Starting...和Request is Ending...这个不是我们在这个文件中独加的，我们将会再任何一个ASP.Net文件中看到它的影子。
ViewStateViewState 这是我们今天重点讨论的；实际上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==
[B] 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的本质，合理的应用它。
ViewState与Session之研究
看了这篇文章写的比较好,转上来了...
昨天偶然看到网上有人讨论究竟是该用viewstate还是session来保存信息. 忽然觉得有必要去深入的研究一下这两个东东了.
我们先来看深入分析一下viewstate, 为了分析的相对完整性,先从简单的说起:
在asp时代, 大家都知道一个html控件的值,比如input 控件值,当我们把表单提交到服务器后, 页面再刷新回来的时候, input里面的数据已经被清空. 这是因为web的无状态性导致的, 服务端每次把html输出到客户端后就不再于客户端有联系.
asp.net巧妙的改变了这一点. 当我们在写一个asp.net表单时, 一旦标明了 form runat=server ,那么,asp.net就会自动在输出时给页面添加一个隐藏域
<input type="hidden" name="__VIEWSTATE" value="">那么,有了这个隐藏域,页面里其他所有的控件的状态,包括页面本身的一些状态都会保存到这个控件值里面. 每次页面提交时一起提交到后台,asp.net对其中的值进行解码,然后输出时再根据这个值来恢复各个控件的状态. 我们再看这个控件的value值,它可能类似如下的形式:Oz4+O2w8aTwxPjs+O2w8....
很多人会认为这是加密的信息,其实不是, ms仅仅是给各个控件和页面的状态存入适当的对象里面,然后把该对象序列化, 最后再做一次base64编码,直接赋值给viewstate控件.
说到这,想必你一定想看看这个viewstate里面到底存了哪些东西, 嗯,你是可以写一个base64 to string的转换代码来实现.不过,viewstate是有层次之分的,普通的转换后,你看到的也是很乱的文字. 这里提供了一个专门转换viewstate值的地方 http://www.wilsondotnet.com/Demos/ViewState.aspx?. 你可以去将自己的viewstate输入进去,让它给你转化一下,这可是带结构的哦
好, 以上说的这些你可能会觉得: 这与session有什么关系? 这个viewstate不是由asp.net自动去维护吗? 是的, 如果仅仅是保存控件的状态, 你可以感觉不到它与session有什么瓜葛( 呵呵,其实它们就没有瓜葛),不过,接下来,我们看看这种使用方法: 在后台aspx.cs代码里:
private void Page_Load(object sender, System.EventArgs e)
{
ViewState["myvalue"] = "viewstatevalue";
//.....
}呵呵, 可以在页面后台直接给viewstate集合赋值, 现在你是不是觉得和session的使用方法差不多了呢? 对,这一点就是几乎所有初学asp.net的人的疑惑. 会认为asp.net也像session那样把这个值保存到服务器内存里面, 其实不是!
那么,这里的viewstate值是属于谁?又存在哪里? 其实,它和上面的其他控件的状态保存一样,也是存储到那个隐藏的viewstate控件值里面, 上面已经说了, viewstate用来保存状态,包括页面本身, 那么,这里的viewstate就属于页面本身的状态.
分析到此,估计大家对viewstate的使用应该是没有什么疑问了. 那么,我们可以来与session做一下类比, session值是保存在服务器内存上,那么,可以肯定,大量的使用session将导致服务器负担加重. 而viewstate由于只是将数据存入到页面隐藏控件里,不再占用服务器资源,因此, 我们可以将一些需要服务器"记住"的变量和对象保存到viewstate里面. 而sesson则只应该应用在需要跨页面且与每个访问用户相关的变量和对象存储上. 另外,session在默认情况下20分钟就过期,而viewstate则永远不会过期.
但viewstate并不是能存储所有的.net类型数据,它仅仅支持String、Integer、Boolean、Array、ArrayList、Hashtable 以及自定义的一些类型.
当然,任何事物都有两面性, 使用viewstate会增加页面html的输出量,占用更都的带宽,这一点是需要我们慎重考虑的. 另外, 由于所有的viewstate都是存储在一个隐藏域里面,用户可以很容易的通过查看源码来看到这个经过base64编码的值.然后再经过转换就可以获取你存储其中的对象和变量值.
其实,对于viewstate的安全性问题,asp.net还给我们提供了更多的选择.一般如果要保护viewstate有两种方式: 一种是防篡改,一种是加密. 一说到防篡改,我们就想起了使用散列代码. 没错, 我们可以在页面顶部加入如下代码:Page EnableViewStateMAC=true
这样asp.net就会自动的在viewstate中追加一个散列码,在页面回传时,服务器根据回传的viewstate生成一个散列码,再与回传的散列码相比较,如果不对,则丢弃该viewstate,同时控件将恢复初试状态. (默认情况下asp.net是通过SHA1算法而不是md5算法来生成散列,不过这个可以在machine.config里面配置machineKey validation="MD5"即可)
而viewstate加密就更简单了, 只要在machine.config里设置一下machineKey validation="3DES"即可实现用des加密viewstate了.
呵呵,至此,我们对viewstate应该有个很清晰的认识了, 不过,初步研究viewstate, 理解有误之处还望大家多指教
