Mike的技术博客

@mikelij 是的，流量大则访问量大，大压力下session丢失是很快的。 而你把viewstate存入session，所以我才说你这方案不靠谱。 viewstate虽然会影响性能，但至少每次回发还是正常保持的。

@pulihe 你在83楼留的言就表达了传统的web form模式不行这一观点。流量一大，你说session会丢失。 这里否定web form的人太多了。当然反对将viewstate放到session中的也很多。我上面的评论也解释了为什么要这么做。剩下的就是个人自己去实践了。再在这里争论也不会出什么结果。你说我这些都无所谓。我想每个人都会面临选mvc还是web form，这是每个人自己的事情。这里只是提供了一些想法。不一定正确。我也想抽空做个试验看看。已经搭了三台虚拟机服务器，都是Win2008。正在构思如何试验呢。估计得写一个mvc应用，还有一个web form应用，最好内容还是一样的。分别做一些性能测试。再把结果列出来。之所以用三台服务器，就是说这些asp.net mvc或者web form的应用都应该是可以跨服务器运行的，如果其中一个服务器坏了。剩下的服务器马上可以将用户的数据继续，用户完全不知道服务器端发生了什么。

@mikelij 你从哪里看出我否定webform了？ 我的态度是指不该用到viewstate的地方就不要用。 我自己的程序都是用webform写的 自己写httpmoudle和httphander来优化性能，自己实现了路由接管，相反我并不用mvc。 一个session压力问题你都扯到webform:no，你太搞了。

ajax+wcf_rest_4.0+js 比较好的开发方式 wcf_rest_4.0解决了大数据传输问题，jquery(ajax)比较灵活，封装比较好.这样一来不仅用户体验效果好而且解决了性能问题，更重要的是安全性提升不少。弊端是开发效率有一点点降低，所以觉得根据实际情况结合起来用，殊不知现在很多大型门户网站都是采用这种方式，只是代表个人观念。

protected override object LoadPageStateFromPersistenceMedium() { object mReturnObj = string.Empty; try { var viewStateID = (string)((Pair)base.LoadPageStateFromPersistenceMedium()).Second; #region 采用Cache的方式 #region 读取Cache方式 var stateObject = HttpRuntime.Cache[viewStateID]; //如果缓存中有数据,那么return缓存的数据 if (stateObject != null) { HttpRuntime.Cache.Remove(viewStateID); mReturnObj = stateObject; } #endregion ////采用AppFabric缓存方式 //var dataCache = DCClass.f_getDataCacheByName(DCClass.mViewStateName); //var stateObject=dataCache.Get(viewStateID); //if (stateObject != null) //{ // return stateObject; //} //else //{ // return String.Empty; //} #endregion #region 采用磁盘文件缓存的方式 //采用磁盘文件缓存的方式,做为Cache失效时读取数据路径 var nowDate = DateTime.Now.ToLongDateString(); var mappath = this.Server.MapPath("~/App_Data/ViewState/"); var tPath = mappath + nowDate; if (!Directory.Exists(tPath)) { Directory.CreateDirectory(tPath); } var fn = tPath + "\\" + viewStateID; var stateStr = string.Empty; stateStr = File.ReadAllText(fn); //if (File.Exists(fn)) //{ // stateStr = File.ReadAllText(fn); // File.Delete(fn); //} #endregion mReturnObj = new ObjectStateFormatter().Deserialize(stateStr); } catch { mReturnObj = string.Empty; } return mReturnObj; }

protected override void SavePageStateToPersistenceMedium(object state) { //产生离散的id号码 var viewStateID = (DateTime.Now.Ticks + this.GetHashCode()).ToString(); #region 采用Cache的方式 #region 放入Cache缓存 //如果服务器硬盘不够,那么不放入缓存,注释掉下面一行 //if (state != null) { Cache.Insert(viewStateID, state); } if (state != null) { //Cache.Insert(viewStateID, state,null, Cache.NoAbsoluteExpiration, TimeSpan.FromMinutes(10), CacheItemPriority.NotRemovable,null); HttpRuntime.Cache.Insert(viewStateID, state, null, Cache.NoAbsoluteExpiration, TimeSpan.FromMinutes(10)); } #endregion //采用AppFabric缓存方式 //if (state != null) //{ // var dataCache=DCClass.f_getDataCacheByName(DCClass.mViewStateName); // //100分钟 // dataCache.Put(viewStateID, state, new TimeSpan(60000)); //} #endregion #region 采用磁盘文件缓存的方式 //采用磁盘文件缓存的方式,做为Cache失效时读取数据路径 //如果要最可靠，可以取消ThreadPool.QueueUserWorkItem //ThreadPool.QueueUserWorkItem(obj => //{ // var value = new ObjectStateFormatter().Serialize(state); // var fn = this.Server.MapPath("~/App_Data/ViewState/" + viewStateID); // File.WriteAllText(fn, value); //}); var value = new ObjectStateFormatter().Serialize(state); var nowDate = DateTime.Now.ToLongDateString(); var mappath = this.Server.MapPath("~/App_Data/ViewState/"); var tPath = mappath + nowDate; if (!Directory.Exists(tPath)) { Directory.CreateDirectory(tPath); } var fn = tPath + "\\" + viewStateID; File.WriteAllText(fn, value); #endregion base.SavePageStateToPersistenceMedium(viewStateID); }

看了这么多觉得写的很好，不过将那么多viewstatus放session里性能会不会出问题，

@ocean 还是不明白你所说的用户是啥。本人所指的用户就是asp.net应用的用户。在这里指责本人扯淡，强词夺理，你看看你的概念是啥？ 从技术上说，viewstate是跟page相关联。你说的没有错。而我想说的是，从商业的角度来说，viewstate和session都是与具体的用户相关联的。之所以将viewstate放session, 是想获得跨服务器的能力，即，当一台服务器坏了的时候，其他的任何一个服务器都可以取得那些原本在坏服务器上用户的session和viewstate，不会中断。这是可伸缩性的要求。只要有可伸缩性，可以通过加服务器的方式来扩展整个系统的服务能力。 当然有不少人不赞成把viewstate放到session。这见仁见智，我该说的我已经说了。还是不能达成一致，没有关系。我也没有试图说服你。我保留意见。 不管怎么说，感谢你愿意花时间提供你的看法。

[quote]mikelij： @ocean [quote]不对，ViewState是和当前页面有关的，而不是和用户有关的。我完全可以只开启ViewState而不开启session，session是否生效根本没什么关系。[/quote] ViewState是和当前页面有关的, 但是归根结底是为用户服务的. 你说是不是与用户相关.[/quote] 你这种说法就属于强词夺理了，我们所说的用户不是一个概念，照你这么说，所有的技术都是和最终用户相关的。这不扯淡吗。我是从技术的角度来说ViewStaten只和当前页面相关。和用户没有任何关系。 对于小网站来说，怎么做都差不多，随便拖拖拽拽就都能搞定。对于大网站来说，这种方法只能让你死的更快。

@Houfeng 你看明白为什么放session呢? 当原来服务用户A的那台服务器突然出问题了, 是不是用户A就得丢失数据呢. 重新再来.

楼主的解决办法不敢苟同，所以标题显然有些大了。 不保存VIEWSTATE方法还是有不少的，就看是要方便还是要性能了。

web form 不只是VIEWSTATE这个问题，还有开发，维护成本的问题。如果是几个模块，是开发的很快，但如果有几十个，就比较麻烦了。在开发上，美工和程序员无法达到各自分工，同时进行。维护上就更困难了，尤其是前期没有架构好，后面接手维护的人就更痛苦了。

再说放session里就是好方法了？

还以为你有什么好见解呢! 如下，微软本来都提供的功能，还用你费时间写出来，浪费大家时间？ protected override PageStatePersister PageStatePersister

ViewState不就是为了保持页面控件的值吗？ 自己封装一个input标签的控件也可以实现啊 如 <input type='text' name='txtValue' value='<%= Request["txtValue"] %>' />

@Steven Xue 你和那个ocean在说viewstate不是与用户相关. 得了, 现在说多了没有多大帮助. 上面也说了, 只做了一个单机的试验,小应用程序根本就看不出有啥改进, 大型没有做试验, 结果未知, 究竟是有帮助, 还是对性能有损害, 现在都很难说. 某些人的观点有可能是正确的.但是不知道是谁的. 大家在这里发表意见, 真的很感谢! 某些意见对本人也是一个提醒. 再次感谢大家!

@Sword-Breaker 你觉得如果是小网站，用得着这么费心吗？那点流量都没人来用。

@mikelij 1.我有一个怀疑，你知道viewstate出现的原因是什么吗？你这样做控件的状态还能得到吗？ 2.你既然知道把每个页面的viewstate存入session，在点击量过大时会出现丢失，您是想将这种方法使用在一天几个点击量的小网站上吗？您觉得如果这样还需要节省那点网络带宽了？ 3.说白了我们做的程序就是在微软制定的规则下进行的，他的规则你可以打破，但你事先得知己知彼。

@mikelij 无力吐槽了,和我想的差不多的反应,我也不在这里浪费时间了...

[quote]mikelij： @刺客之家 [quote]1、如果有人否定webform，那也不是仅仅因为viewState太大，而是这种开发模式掩盖了本质的Web,很多人不喜欢，他们喜欢更多的控制权、简单的Html、自动化测试支持，等等。 2、关于viewState,在正常的web应用中，需要保持页面数据的地方，如果有后台交互一般都ajax,所以压根没有使用viewState来保持页面数据的需求了 3、楼主不要再纠结于各种方法来实现viewState,因为你还在那个圈子里转 4、Webform是成功的，也是失败的。成功在于当年他吸引了很多Winform的开发人员顺利的转移到B/S开发中来，想当然的使用着各...[/quote] 1、如果你看到.aspx,那不一定是webform哦。 2、谁爱用什么用什么，咱管不着，webform和mvc的区别我都谈过了。大家自己根据情况选择就o了