SubmitOncePage：解决刷新页面造成的数据重复提交问题

执行过postback操作的web页面在刷新的时候，浏览器会有“不重新发送信息，则无法刷新网页”的提示，若刚刚执行的恰好是往数据库插入一条新记录的操作，点[重试]的结果是插入了两条重复的记录，以前一直是用保存数据后重新转向当前页面的方法解决，最近又找到了一个新的方法。

问题分析

在System.Web.UI.Page类中，有一个名为ViewState属性用以保存页面的当前视图状态，观察每个aspx页面最终生成的html代码可以发现，其实就是向页面添加了一个名为__VIEWSTATE的隐藏域，其value值就是页面的当前状态，每次执行postback过后，该value值都会发生变化，而刷新页面则不会改变。

针对这种情况，我们可以在页面代码执行的末尾将当前的ViewState写到一个Session中，而在页面加载时则判断该Session值是否与当前ViewState相等（其实Session值恰好是ViewState的前一状态），若不等，则是正常的postback，若是相等则是浏览器刷新，这样一来，只要在我们的数据插入代码外嵌套一个if判断就可以达到防止数据重复提交的目的了。

其实到这里问题还没有完全解决，具体说来就是Session的键值问题。假设我们将ViewState保存为this.Session["myViewState"]，如果一个用户同时打开两个防刷新提交的页面就乱套了，那针对页面的url设置Session的键值呢？还是不行，因为用户有可能在两个窗口中打开同一页面，所以必须为每次打开的页面定义唯一的Session键值，并且该键值可以随当前页面实例一起保存，参考ViewState的保存方式，我们直接向页面添加一个隐藏域专门存放Session键值就可以了。

经oop80和Edward.Net的提醒，为了尽可能地降低Session数据对服务器资源的占用量，现将上述方案略做调整，将ViewState利用md5加密后返回的32位字符串写入Session。

另外，由于本方法会生成额外的Session占用服务器资源，所以请在必须保留当前页面状态的情况下使用，若无需保留当前页面状态，则在完成数据提交后直接重定向到当前页面即可。

SubmitOncePage

SubmitOncePage是针对上述分析写的一个继承自System.Web.UI.Page的基类，需要防止刷新重复提交数据的页面从该基类继承，源码如下：

namespace myControl
public class WebForm1 : myControl.SubmitOncePage

7、按F5运行，在浏览器窗口中连续点击几次Button1，然后刷新几次页面，再点击几次Button1；
8、转到测试项目对应目录下，打开a.txt和b.txt文件，可看到if (!this.IsRefreshed) 的具体效果。

# re: SubmitOncePage：解决刷新页面造成的数据重复提交问题 2005-12-25 22:02 Edward.Net
希望不要保存到Session中去，在中小型项目中还可接受，如果在大型项目中并发量大页面访问比较多而且页面数据相对较多的情况下很容易会造成服务器内存很快就会被耗尽的，应该尽量减少这种无效的冗余数据的使用。现在我们公司的产品就是由于在使用Session的时候没有认真考虑，现在登陆以后一直到需要测试的页面aspnet_wp进程占用的内存就会达到100M左右，更别说投入正是使用了。现在客户那里3G的内存都感觉很吃劲。 回复 更多评论


# re: SubmitOncePage：解决刷新页面造成的数据重复提交问题 2005-12-26 11:11 oop80
这样的方法有问题的，
第一个是内存占用，你这样做，在正常操作环境下，会产生大量的废session，单用户可能感觉不到，但是一旦很多用户同时操作的时候，那就相当可观了。
第二，效率问题。如果viewstate很大，而不幸的又多按了几次f5，那么你的服务器就又多点事情要做了，想想看，比较两个100k的相同文本，会消耗服务器多少的资源，如果这个viewstate有1m呢？当然，在正常的操作下面（没有按f5），比较的效率应该还是可以的。
第三，兼容性问题，现在ms的viewstate是这么设计的，但是万一以后变掉了，f5以后viewstate还是会变，那怎么办？况且，目前viewstate在f5情况下不变，也是你试验出来的吧，似乎没有官方的说法可以证实这一点，这也是需要考虑的地方 回复 更多评论