主题：请教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？可我也不是干这一行的啊，一定要学这么多吗？ 哭！！！！！