下午看到木野狐的一篇名为《ASP.NET 小技巧：重写 ViewState 的存储目的地，以提高页面性能》的文章，记得以前看到过关于压缩ViewState保存以达到提高页面访问速度的文章，不管怎么样，这些都是些优秀的内容。但是看到后面跟的一堆评论，我不免产生一个疑问：到底ViewState的使用范围有多大？为什么经常会看到说ViewState会保存大量数据内容？
一个是改变ViewState的存储位置，一个是压缩ViewState，怎么看都觉得好象ViewState让人感觉是引起“性能损失，访问变慢”的罪魁祸首。可是事实上，ViewState是这样的吗？
由于HTTP是无状态协议，因此在基于B/S结构的应用中，状态管理一直是有一定讨论内容的话题。有时候面试ASP.NET程序员，都会把列举ASP.NET状态管理的方法做为一个题。而也正因为有了多种不同的状态管理的方法，所以也间接导致了部分情况下ViewState成了让人不舒服的东西，所以才会有人去改变存储位置，去压缩。
ViewState是ASP.NET特有的一个内容，而Session、Cache、Cookies、Application这些在其他一些WEB开发方式中也并不陌生。但是不管怎样，这些都是ASP.NET中保存状态信息的一些方法。但是严格说，ViewState与其他几种方式最大的差别就是它的生命周期。
ViewState其实最初设计的目的是提供给组件开发人员使用的，但是由于Page对象也存在一个StateBag对象的ViewState，所以往往更多的人把ViewState看作为保存页面临时状态的方法。但是不管怎么样，熟悉ViewState工作模式的人就会知道，它开始于PostBack以后Page对象的LoadViewState（Page的Child Controls随即也逐个调用LoadViewState），结束于Page对象的SaveViewState，其他时候，它就是一串晦涩的字符串。所以，严格说ViewState的生命周期就是Request-Response。
记得有本技术书籍提到过木野狐的更改ViewState的保存位置的方式加快访问速度，但是那里说的是保存到一个数据库中，这种方式我一直表示怀疑。现在旧事重提，我不得不发表些个人观点。其实我一直认为，ViewState保存大数据除非是不得已，否则还是不建议那么做，我以前写的一个层级下拉框的代码就因为用ViewState保存DataSource被我枪毙，所以到现在也没有扶正，虽然demo仍然放在网上，不少人还问我要代码。但是我自己一直没有用它。
一个是改变ViewState的存储位置，一个是压缩ViewState，怎么看都觉得好象ViewState让人感觉是引起“性能损失，访问变慢”的罪魁祸首。可是事实上，ViewState是这样的吗？
由于HTTP是无状态协议，因此在基于B/S结构的应用中，状态管理一直是有一定讨论内容的话题。有时候面试ASP.NET程序员，都会把列举ASP.NET状态管理的方法做为一个题。而也正因为有了多种不同的状态管理的方法，所以也间接导致了部分情况下ViewState成了让人不舒服的东西，所以才会有人去改变存储位置，去压缩。
ViewState是ASP.NET特有的一个内容，而Session、Cache、Cookies、Application这些在其他一些WEB开发方式中也并不陌生。但是不管怎样，这些都是ASP.NET中保存状态信息的一些方法。但是严格说，ViewState与其他几种方式最大的差别就是它的生命周期。
ViewState其实最初设计的目的是提供给组件开发人员使用的，但是由于Page对象也存在一个StateBag对象的ViewState，所以往往更多的人把ViewState看作为保存页面临时状态的方法。但是不管怎么样，熟悉ViewState工作模式的人就会知道，它开始于PostBack以后Page对象的LoadViewState（Page的Child Controls随即也逐个调用LoadViewState），结束于Page对象的SaveViewState，其他时候，它就是一串晦涩的字符串。所以，严格说ViewState的生命周期就是Request-Response。
记得有本技术书籍提到过木野狐的更改ViewState的保存位置的方式加快访问速度，但是那里说的是保存到一个数据库中，这种方式我一直表示怀疑。现在旧事重提，我不得不发表些个人观点。其实我一直认为，ViewState保存大数据除非是不得已，否则还是不建议那么做，我以前写的一个层级下拉框的代码就因为用ViewState保存DataSource被我枪毙，所以到现在也没有扶正，虽然demo仍然放在网上，不少人还问我要代码。但是我自己一直没有用它。
