主题：请教ASP.NET编程的大牛 （拜托转相关版面） -- 吴刚看你跳舞

你们是怎么解决statelessAsynchronous问题的？

比如说，我正在看一个bbs，点了“回复”按钮，要回复一个帖子，可是在我看帖子到我点按钮这中间，帖子的主人已经删除了这个帖子。这样当我postback的时候，重新生成的页面就对不上原来的页面了，“回复”按钮也对不上。这种情况应该怎样避免？多谢

• 继续请教，兼谢谢懒厨，铁手，请尽量

否则转了过去你就无法回复了。

当postback的时候，server要先根据session或database 里的记录，重新复制一个和当初发给client 一模一样的页面，然后才能根据发回来的信息，理解客户端的要求，比如说 "ID为293479的帖子上的“回复”按钮"被按了。如果这之前帖子293479已经被作者删了，复制出来的页面就不存在 “Button_Reply_293479”这样一个控件，它怎么去理解呢？当然可以抓exception，但是我觉得很笨啊，

这是我想在同一个页面中实现 编辑/回复 功能才会遇到的问题，如果把 回复 按钮link到 replyForm.aspx?ID=293479，那就省心了。

多谢铁手的回复。我只懂一丁点儿 asp.net，还不通。要是哪位知道serverlet 的 页面周期设计上 有什么关于同步的考虑的话，还望赐教。

我现在就是先用webservice先叫一下server，然后再提交的。但是这么做，第一，觉得很怪，第二，其实还是存在不能同步的问题，假如 检查完了-----提交回复之间， 作者删了帖子呢?

要是我来做，删除帖子的操作，我不会删除有关数据记录，而是把那条记录标记成“已删”，这样当您递交会贴的时候，不会存在Ｒｅｆｅｒｅｎｃｉａｌ　ｉｎｔｅｇｒｉｔｙ的问题。

产生页面的时候，如果发现记录标记成“已删”，就产生另一个页面就是。

如果担心太多已删纪录，可以定期清除的。

谢谢懒厨，这是很好的办法，两三个月清一次就好。

但假如两个人同时修改一个条目呢，而且条目内容动态决定前端特性，比如说一个日程安排条目如果截止日期在24小时之内，那么前端页面上要可以响闹铃。好，当用户A关闹铃时，后面用户b 已经把截止日期调到两周后了.....

也就是说要完全解决这个ri问题，我必须得做一个sourceSafe.

我认为万恶之源都在于http的stateless，想从根子上解决，只有1）session存生成的页面，2）session存datasource。 存page object要大改life cycle,不值得。可是存页面，重新生成event太麻烦，存datasource，内存受不了。请教方家，有没有十全十美 :)的好办法

即使用传统的Ｃｌｉｅｎｔ－Ｓｅｒｖｅｒ也会遇到同样的问题。常见的解决方法是，每条记录都有最后更新时间，或者一个ＧＵＩＤ，每条纪录更新时，这个域都会自动更新。

更新纪录时，总得先读出来，在写进数据库时，ｓｔａｒｔ　ｔｒａｎｓａｃｔｉｏｎ，锁住相关纪录，对比一下之前读出来的最后更新时间，或者一个ＧＵＩＤ，如果没问题，就更新，否则ｒｏｌｌｂａｃｋ　ｔｒａｎｓａｃｔｉｏｎ，更新失败。

• 不懂ASP.NET。不过，这个听起来怎么象是典型的

这样，后面的人要修改的时候，系统就可以提醒说已经有人在修改过程中。前一个人修改完毕后，后面的人就可以继续修改了。

标记之后，突然断了线，这个帖子就变成“一直在改”了！

多用户数据库的记录更新问题啊？你的这部分代码在准备提交自己的更改前，应该试图锁住你要修改的数据库记录。

底下懒厨的答复应该指出了解决办法：这个似乎和ＨＴＴＰ没有太大关系

各位高手建议的，比较经典的在数据库端作标记的pattern，实际上是：

update修改过的数据条目,并且标记修改的时间。也就是说数据内容已经改了，我们只有“改”的信息，但是找不回未改之前的数据。这样对于经典的bbs就足够好了。

比如说

这里面的UI端的，可以用作postback的选项：转发，回复讨论，主题留言等等，现在都是js 打开新页面，其实和我的问题不相干（不考虑窗口间通讯的话）。但是假如客户就要求在一个页面里做，那就很可能要postback，（javascript call webservice 的情况等下再说）。

现在 故事一开始了：

sequence:

1.userA loaded page

2.userB deleted this record (mark IsDeleted 1)

3.userA clicked "回复讨论" 按钮，postback

这个情况是没有问题的，懒厨和铁手给出的办法都好用。

具体过程是这样的：if IsPostback,按照asp.net的规矩,重新生成页面（蠢事），要求这个页面跟当初发送给客户端的页面完全一致。然后系统会报(从客户端来)哪个html元素A被激活了导致postback，再从 新生成的页面里把这个元素A'挑出来，这时候A'和他生成时的数据对象A''还绑在一起，我们就可以对A''下手了。最后系统把整个页面对象转成html，发回客户端。

故事一中，userA click "回复讨论" 按钮，postback以后，因为数据库里还没删掉这条记录，所以还可以生成和当初一致的帖子对象，所以可以“追溯”到是哪个帖子的"回复讨论" 按钮引发的事件。对此事件的处理中，再检验是不是已删除，要不要报告客户端之类的。整个流程都没有问题。

没有问题的关键是：中间这一步：“追溯”到是哪个帖子的"回复讨论" 按钮引发的事件， 并不需要知道帖子被修改前的内容。也就是说数据内容已经改了，我们只有“改”的信息，但是找不回未改之前的数据，没有关系。

可是故事二来了：

铁手加了个规矩：只有帖子里有加粗字段的，才会有“回复讨论”选项，我这个帖子里有加粗记号。

sequence：

1.userA loaded page，page里这个帖子，有“回复讨论”选项，

2.userB changed this record，deleted all BOLD signals。

3.userA clicked "回复讨论" 按钮，postback

4.Server regenerated page

5.Server can not understand which 帖子 cause this event

........

所以我的问题不是怎样在数据库端维护完整性，而是怎么认识html元素引发的事件，并把它跟数据条目联系起来。所以我才说stateless是万恶之源。

我想过好多种解决办法，都有问题：

1）还在数据库里下功夫，把帖子修改前的内容也存下来，override update，变成insert。这要是碰上复杂一些的relationship。。。。。

2）一个session，一个dataset,存在staticObjects里，把问题转嫁到后端去。dataset吃内存很可怕的

3）Multi version Caching of User Control。 这个适用范围不广。首先event recognzing 就有问题，其次照顾user control hierarchy 特别麻烦。尤其是像我这样，整个网站只有一个页面的。

4）可能是终极解决办法了，也特别符合fat-client的潮流，就是下定决心，排除万难，去写一个javascript page admin system，比现在市面上的几个都要好，要快，要全面，所有的问题都交给js call webservice， 根本就没有postback， 把浏览器变成你的winform。这么做其实也还过得去，除了一点：所有的business logic都暴露在客户端了。。。。。。。

5）要不我改学java？可我也不是干这一行的啊，一定要学这么多吗？ 哭！！！！！

开新贴自己指自己

我坦白，我还真没在web环境下做过数据库编程。以前那点儿经验都是在UNIX主机环境下的。要是这个问题比较蠢，别打我。