ASP.NET编程中Web页面几种状态管理总结

C#cookie自动获取工具

• 类型：站长工具大小：5KB语言：中文 评分：7.5
• 标签：

立即下载

ApplicationState

应用程序状态是指采用HttpApplicationState实现的状态维持方式，使用代码如下：

Application.Lock();
Application["PageRequestCount"] = ((int)Application["PageRequestCount"]) + 1;
Application.UnLock();

对于这种方法，我不建议使用，因为：
1. 与使用静态变量差不多，直接使用静态变量可以不需要字典查找。
2. 选择强类型的集合或者变量可以避免装箱拆箱。

ViewState，ControlState

视图状态，控件状态，二者是类似，在页面中表现为一个hidden-input元素：

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="......................" />

控件状态是ASP.NET 2.0中引入，与视图状态相比，它不允许关闭。
由于它们使用方式一致，而且视图状态是基于控件状态的实现逻辑，所以我就不区分它们了。

在ASP.NET的早期，微软为了能帮助广大开发人员提高开发效率，引用入一大批的服务端控件，并为了能将事件编程机制引入ASP.NET中，又发明了ViewState。

这种方式虽然可以简化开发工作量，然而却有一些限制和缺点：
1. 视图状态的数据只能用于回发（postback）。
2. 视图状态的【滥用】容易导致生成的HTML较大，这会引起一个恶性循环：
　　a. 过大的ViewState在序列化过程中会消耗较多的服务器CPU资源，
　　b. 过大的ViewState最终生成的HTML输出也会很大，它会浪费服务端网络资源，
　　c. 过大的ViewState输出导致表单在下次提交时，会占用客户端网络资源。
　　d. 过大的ViewState数据上传到服务端后，反序列化又会消耗较多的服务器CPU资源。
　　因此，整个交互过程中，用户一直在等待，用户体验极差。

在ASP.NET兴起的年代，ViewState绝对是个了不起的发明。
然而，现在很多关于ASP.NET性能优化的方法中，都会将【关闭ViewState】放在头条位置。
为什么会这样呢，大家可以自己思考一下了。

有些人认为：我现在做的程序只是在局域网内使用，使用ViewState完全没有问题！
然而，那些人或许没有想过：
1. 未来用户可能会把它部署在互联网上运行（对于产品来说就是遇到大客户了）。
2. 项目早期的设计与规划，对后期的开发与维护来说，影响是巨大的，因为许多基础部分通常是在早期开发的。
当这二种情况的任何一种发生时，想再禁用ViewState，可能已经晚了。

对于视图状态，我认为它解决的问题比它引入的问题要多要复杂，
因此，我不想花时间整理它的优缺点，我只想说一句：把它关了，在web.config中关了。

另外，我不排斥使用服务器控件，我认为：你可以使用服务端控件显示数据，但不要用它处理回发。

如果你仍然认为视图状态是不可缺少的，那我还是建议你看看ASP.NET MVC框架，看看没有视图状态是不是照样可以写ASP.NET程序。