违背历史车轮的 VIEWSTATE
 

前端时值乱世,烽烟四起,群雄割据,民不聊生,W3C标准一套接一套,仍无法改变当今乱世,生于此代的UI人员可谓处于水深火热之中...成为WEB标准化道路上的牺牲品. 

再来谈谈VIEWSTATE,这个所谓的"状态保持机制"看似很方便,但这个机制完全就是与WEB标准化背道而驰!所有控件的状态全部转化成_VIEWSTATE发回服务器,大部分数据通常并未使用,再由服务器编码发回来,耗费巨大网络带宽、服务器资源。它仅仅是为了让开发人员可以像WinForm一样实现傻瓜开发。 

AJAX使局势出现了转机，若再得到WEB标准方案的出台，一统乱世，天下大同，为时不远，实乃众望所归。  
 


------解决方案--------------------
天下WEB大势,合久必分,分久必合！
------解决方案--------------------
VIEWSTATE的确是Input type=hidden的旧瓶新酒,但是他不和AJAX冲突,AJAX也是XMLHTTP的旧瓶新酒而已.
------解决方案--------------------
不好妄下断言,如你我之辈都能看出这么大的问题来,估计微软也挺不到今天了.
------解决方案--------------------
asp.net的ViewState是从2000年开始设计，或者最晚可以说是2002正式推向市场的。那么请问，有没有一套Ajax组件产品今天“已经”取代了asp.net服务器控件？

实际上，Ajax一直只是一种非常不成熟的脚本语言。如果它是成功的，也就没有RIA了。

至于说ViewState“保存在网页上”，只是一种实现方法而已。早在asp.net1.0中（6年以前）就已经设计好了这个接口（可以看到它是Virtual的方法），通过重载 SavePageStateToPersistenceMedium 和 LoadPageStateFromPersistenceMedium 两个方法，使用不超过15条语句，就可以把整个ViewState数据缓存在服务端文件中，那么此数据读取速度不是“网络速度”而是“本地磁盘读写速度”。至于为什么要保存在内存以外，很简单，web服务器以很低的硬件配置要服务于成千上的互联网用户，自然与c/s系统服务器的设计完全不一样。

至于说asp.net2.0，更是早已经用可重载 PageStatePersister 属性来稍稍简化了上述两个方法。

你这个问题，跟对asp.net的了解深度有关。

------解决方案--------------------
找到了以前回的一个帖子。

http://topic.csdn.net/t/20061020/21/5098172.html

当然在asp.net2.0中可以以 PageStatePersister 方式实现。

可以看看，如果你学习asp.net所使用的教材中没有对这种基本知识的讲解，那么这种教材一定不是讲解asp.net内部运行机制而是面向初学者的，或者虽然讲解但是是含糊的（例如某些不负责任的出版者包装的asp.net技术教材）。
------解决方案--------------------
对于ViewState的了解，以及对于Cache API的了解，是我判断一个程序员是否深入了解asp.net的两个指标。前者，可以判断一个程序员是否能够正确地开发业务中间件，后者则用来判断一个程序员是否能够正确地做应用程序优化。
------解决方案--------------------
关注~
------解决方案--------------------
留个名，关注
------解决方案--------------------

探讨

对于ViewState的了解，以及对于Cache API的了解，是我判断一个程序员是否深入了解asp.net的两个指标。前者，可以判断一个程序员是否能够正确地开发业务中间件，后者则用来判断一个程序员是否能够正确地做应用程序优化。

------解决方案--------------------
微软新推出的asp.net mvc，算是对viewstate的一个否决吧，他自己都说了，这是一种回归传统web开发的模式，不支持postback。
说明所谓的viewstate确实有性能上的问题吧
------解决方案--------------------
Mark,,今天累了，明天再看
------解决方案--------------------

探讨

微软新推出的asp.net mvc，算是对viewstate的一个否决吧，他自己都说了，这是一种回归传统web开发的模式，不支持postback。
说明所谓的viewstate确实有性能上的问题吧

------解决方案--------------------

探讨

SP1234,

我觉得你的办法还是没有完全地瞄准WEB发展趋势。

------解决方案--------------------
你可以对整个asp.net是否必要进行重新讨论。但是，不要使用错误的论据。我也在上面说过将状态数据保存在内存中，于性能和稳定性方面都不符合web服务的基本要求，这大概只有开发过多用户终端的人才能实际感受到。至于开发“胖客户端”的c/s程序，并以此说“瞄准WEB发展趋势”就是那种将状态保存在客户端的做法，则是与历史事实不符的。在7、8年前asp.net1.0开始开发的时候，不可能以及将今天的silverlight都设计出来了，不可能那是就随便说说“最根本的办法，就是不将前端的任何多余资料暂存于服务器”，还是要实事求是地去看待每一种技术。
------解决方案--------------------
在7、8年前asp.net1.0开始开发的时候，不可能已经将今天的silverlight都设计出来了，不可能再那时就随便说说“最根本的办法，就是不将前端的任何多余资料暂存于服务器”，还是要实事求是地去看待每一种技术。
------解决方案--------------------