62,242
社区成员
发帖
与我相关
我的任务
分享asp.net 审核系统设计
要实现一条信息在添加、修改、删除时都需要管理员审核，怎么设计，大家帮帮忙。
1、在添加时可以给个字段默认不通过，管理员点击审核通过及改变状态即可。
2、在修改数据提交后，怎么让审核呢，是不是需要单独设计一张表保存修改提交的数据，管理员打开修改审核页面时从这张表中取数据列表显示，然后选择一项，审核通过后程序在修改原数据。
3、删除时，选择要删除的项的编号，提交到一张表中，管理员进入删除审核页面时，从这张表和信息表关联查出数据列表显示，管理员点击审核通过，及删除该条信息。
我还有一个思路是，审核人员只有审核的权限而不是在审核后修改或删除用户信息，
所以用户端修改和删除按钮先灰掉不可用，待审核通过后可以看到审核状态，然后自己在修改和删除数据。
希望有经验的朋友告诉我怎样处理比较合理
1、在添加时可以给个字段默认不通过，管理员点击审核通过及改变状态即可。
2、在修改数据提交后，怎么让审核呢，是不是需要单独设计一张表保存修改提交的数据，管理员打开修改审核页面时从这张表中取数据列表显示，然后选择一项，审核通过后程序在修改原数据。
3、删除时，选择要删除的项的编号，提交到一张表中，管理员进入删除审核页面时，从这张表和信息表关联查出数据列表显示，管理员点击审核通过，及删除该条信息。
我还有一个思路是，审核人员只有审核的权限而不是在审核后修改或删除用户信息，
所以用户端修改和删除按钮先灰掉不可用，待审核通过后可以看到审核状态，然后自己在修改和删除数据。
希望有经验的朋友告诉我怎样处理比较合理
...全文
请发表友善的回复…
发表回复
lei00529 2012-09-27
- 打赏
- 举报
加一个数据审核表，
表结构：
ID:自增长
状态：是否审核
类型:增加,修改，删除
数据详细：以json格式存储数据。
在管理员审核通过之后，再把json数据反序列化为对象，然后调用相应的add，update,delete，然后收工。
表结构：
ID:自增长
状态：是否审核
类型:增加,修改，删除
数据详细：以json格式存储数据。
在管理员审核通过之后，再把json数据反序列化为对象，然后调用相应的add，update,delete，然后收工。
zh520 2012-09-24
- 打赏
- 举报
增加信息比较好处理，主要是在修改一条信息后也要去审核，该怎么处理啊
以专业开发人员为伍 2012-09-24
- 打赏
- 举报
[Quote=引用楼主 的回复:]
我还有一个思路是，审核人员只有审核的权限而不是在审核后修改或删除用户信息，
所以用户端修改和删除按钮先灰掉不可用，待审核通过后可以看到审核状态，然后自己在修改和删除数据。
希望有经验的朋友告诉我怎样处理比较合理
[/Quote]
没有必要把事情设计得的那么复杂。
你发过电子邮件吗？电子邮件中我们“回复”信息，就和这种工作流很像。实际上就是。
我还有一个思路是，审核人员只有审核的权限而不是在审核后修改或删除用户信息，
所以用户端修改和删除按钮先灰掉不可用，待审核通过后可以看到审核状态，然后自己在修改和删除数据。
希望有经验的朋友告诉我怎样处理比较合理
[/Quote]
没有必要把事情设计得的那么复杂。
你发过电子邮件吗？电子邮件中我们“回复”信息，就和这种工作流很像。实际上就是。
devmiao 2012-09-24
- 打赏
- 举报
建议使用工作流实现权限和审核功能。具体可以Google下，先掌握相关基础知识，再用现成的库。
小纯洁001 2012-09-24
- 打赏
- 举报
[Quote=引用 4 楼 的回复:]
不论是是用户端还是管理员，其实都不会直接去修改或者删除信息。删除或者修改信息的是电脑，是这个流程（尽管只有3步就结束了）走到最后一步时系统自动处理的。
所以用户端“先灰掉两个按钮”是没有意义的，它不应该在工作走到下一个流程时再去做修改，它顶多只能“撤销申请”而已。
比如说管理员不同意审核通过，那么操作退回给用户端，那么工作流就是“用户录入-审核-用户再录入-再审核-审核通过-系统更新……
[/Quote]
不论是是用户端还是管理员，其实都不会直接去修改或者删除信息。删除或者修改信息的是电脑，是这个流程（尽管只有3步就结束了）走到最后一步时系统自动处理的。
所以用户端“先灰掉两个按钮”是没有意义的，它不应该在工作走到下一个流程时再去做修改，它顶多只能“撤销申请”而已。
比如说管理员不同意审核通过，那么操作退回给用户端，那么工作流就是“用户录入-审核-用户再录入-再审核-审核通过-系统更新……
[/Quote]
xuwenxiang888 2012-09-24
- 打赏
- 举报
何必要自己绕自己？
如果只有一个系统管理员，写死也行，根据名字判断呗，如果权限是可以更换，那当然是建权限表更好。在处理操作时，根据权限判断。这个就又分为，进入页面时，如果没权限，压根看不到按钮，只能浏览；或者是在点击修改，删除的时候，再判断用户是否有权限执行操作。如果为了页面的完整性和一致性，肯定是第二种，提交时在判断更好，如果为了省事，当然是用户进入页面变判断更好。
如果只有一个系统管理员，写死也行，根据名字判断呗，如果权限是可以更换，那当然是建权限表更好。在处理操作时，根据权限判断。这个就又分为，进入页面时，如果没权限，压根看不到按钮，只能浏览；或者是在点击修改，删除的时候，再判断用户是否有权限执行操作。如果为了页面的完整性和一致性，肯定是第二种，提交时在判断更好，如果为了省事，当然是用户进入页面变判断更好。
以专业开发人员为伍 2012-09-24
- 打赏
- 举报
不论是是用户端还是管理员，其实都不会直接去修改或者删除信息。删除或者修改信息的是电脑，是这个流程（尽管只有3步就结束了）走到最后一步时系统自动处理的。
所以用户端“先灰掉两个按钮”是没有意义的，它不应该在工作走到下一个流程时再去做修改，它顶多只能“撤销申请”而已。
比如说管理员不同意审核通过，那么操作退回给用户端，那么工作流就是“用户录入-审核-用户再录入-再审核-审核通过-系统更新数据”这样的流程。一个工作流就好象赫拉克利特所说的“不能两次踏入同一条河流”一样，每一个步骤都创建新的痕迹，而不会重复。
不论流程怎样走，画面上只要监视后台系统（或者数据库系统）并刷新界面就行了。因此就算是一个表达从画面上看似没有什么变化，而后台业务系统可能已经走了一大圈流程了！
所以用户端“先灰掉两个按钮”是没有意义的，它不应该在工作走到下一个流程时再去做修改，它顶多只能“撤销申请”而已。
比如说管理员不同意审核通过，那么操作退回给用户端，那么工作流就是“用户录入-审核-用户再录入-再审核-审核通过-系统更新数据”这样的流程。一个工作流就好象赫拉克利特所说的“不能两次踏入同一条河流”一样，每一个步骤都创建新的痕迹，而不会重复。
不论流程怎样走，画面上只要监视后台系统（或者数据库系统）并刷新界面就行了。因此就算是一个表达从画面上看似没有什么变化，而后台业务系统可能已经走了一大圈流程了！
winner2050 2012-09-23
- 打赏
- 举报
你们公司让初学者搞设计啊？
