Web应用程序中，有很多状态需要在页面的反复回调中能够保持住，还有一些状态需要在页面之间保持。对于状态的保持，是一个值得研究的问题。状态处理不当是页面失效或错误的一个重要的原因。
对于ASPX页面来说，控件可以通过VIEWSTATE来保持状态。VIEWSTATE机制非常好用，有时甚至可以用来保存页面后台代码中属性变量的状态值：因为变量的状态在回调时是不保存的，但是控件的状态却可以保持，因此可以通过控件来保持变量的状态，把控件设置为隐藏状态就不影响页面显示了。
但是VIEWSTATE却不能包打天下，我们的很多页面处理，都是以URL调用的方式进行的，如分页浏览，每次通过分页器进行的跳转都是新开页面，无法使用VIEWSTATE。
分页处理中，使用了URL参数来传递状态，这种传递方式简单明了，但也存在问题：
1、复杂。需要在URL中把各种状态全部写进去，一个都不能少。参数数量众多，考虑不周往往容易遗漏，还不好找原因。
2、和其他方式之间的协调问题。因为页面本身可能有回调操作，比如查询，或者其他的需要回调页面的控件操作，URL参数和回调参数之间的协调必须要精确的处理好。
特别是第二点，在分页浏览中体现得非常明显：既要能在不指定查询条件的情况下浏览所有数据，又要能够支持在回调事件中处理查询操作，还要能够把查询条件传递给新的分页器。要实现这一要求，只能借助复杂的处理逻辑来实现了。
这种需要在URL中传递所有参数的方式，在构造分页器链接的时候需要把页面所需的参数都显式地进行传递。当页面还有其他参数，特别是和分页无关的参数的时候，就会很难控制。构造分页器时，要去解析和分页无关的参数，要进行参数集合重复性的判断以及决定究竟哪个参数有效等。这些操作对于分页处理程序而言，既不合理也是隐患多多的。
基于页面的参数保持机制
参数传递的种种不便之处，使人不禁想到，为什么非要使用URL呢？URL方式，适合传递一些变化的参数。而上述的问题，都是由于一些需要保持的参数的传递而引起的。对于参数的保持，还有更加合适的手段：如Session或者Cookie。
那么，究竟选择Cookie还是Session呢？Session是一个进程级别的状态保存机制，在整个浏览过程中，在打开的所有页面之间，Session保存的数据都会有效。但Session也存在不足：
1、Session存放在服务器端，占用服务器的资源；
2、多个页面公用Session变量，容易导致混乱，如果每个页面都分别创建Session变量，则又造成资源的浪费；
3、Session本身有失效周期，在一些需要长期打开工作的页面，带来页面失效问题。
而Cookie相对来说，正好没有Session的不足。首先，Cookie不占用服务器资源，其次，Cookie按键-值的方式存储，正好可以用每个页面的名称为key，存储每个页面的状态。
根据各种应用的需要，基于页面的状态保持机制应该达到如下的要求：
1、页面回调时保持状态
2、页面跳转时保持状态
3、以Cookie方式存储数据
4、通过索引器的方式访问
5、兼容各种状态机制，自动尝试从URL、Session、Cookie中获取需要的参数值
6、只要使用过的参数，自动保持到Cookie中