审核功能实现

1、普通

方案：经办时入A表，审核后从A表读取数据，然后操作目标B表；

优势：思路简单

劣势：对后端功能实行高度的嵌入；审核功能数据操作不统一

 

2、弹框式

方案：前台实现，操作时判断是否需要权限控制，如果需要，则弹出框，由审核人员进行审核，

审核通过后，进行后续操作。

 

优势：对后台功能无嵌入；可支持查询、导出、操作等全部功能；

劣势：需要经办人和审核人同时在场操作

 

3、入参缓冲时

方案：审核功能是独立的功能，前台发起业务后，入参存入数据库。

待审核通过后，后台触发调用相应的接口，并将执行结果通知到经办人。

优势：对前后台功能均无嵌入；支持导出及操作类；经办人和审核人可以异步操作；审核功能数据操作统一；

劣势：需要框架层支持；实现逻辑稍微复杂

 

4、临时表

方案：所有需要审核功能涉及的表均增加相应的表，该表比源表主要增加1个字段，即审核流水，其余字段命名完全一致；

所有功能操作时先入该表，审核通过后，由后台从该表将数据同步至正表。

优势：无需要框架支持；支持导出及操作类；经办人和审核人可以异步操作；审核功能数据操作统一；

劣势：对后端功能实行高度的嵌入；

 

建议1：比较倾向于方案2、3；方案2在操作上同银行柜台操作方式比较类似，但是不符合异步式的工作方法。

方案3比较理想，但是需要在框架层实现。

 

建议2：不实现审核，改用审计功能，对于中小系统而言比较合适。此外，可以和预警系统配合，整体上实现风险可控。

建议3：当然，以上不是一成不变的，因系统性能、管理、习惯等问题，可以将以上方案进行综合，从而形成自己特有的方案。