帮助crud程序员思考“批准工作流”[已关闭]

批准=状态更改

state change==更新更改的内容,创建日志以记录更改的内容。

就是这样。

有趣的规则是“谁可以做更新?”,“哪些状态更改是合法更新?”,以及“哪些州是死胡同?”

你在建造一个有限的自动机。状态是对象的属性。你可以通过更新工作流的状态来推动它。

这里有一些设计模式。也许他们能帮上一点忙:

http://en.wikipedia.org/wiki/Workflow_patterns

工作流比简单的crud应用程序更受状态驱动,所以是的,阅读状态机模式也会有帮助。听起来你走对了。

对于数据建模,可以有一个包含所有“批准”的表,其中的状态字段是状态表的外键。

至于通知,这是你的应用程序在更改审批状态时必须做的事情,它将必须查找其他地方,以查看需要通知哪些人/哪些内容以进行特定的状态更改(因此,你必须跟踪哪些实体因哪些状态更改而得到通知)。

正如许多人所说,批准它将使它进入一个新的状态。

需要考虑的是,我经常发现用户希望事物处于相同的“状态”,但也记录了事物处于不同的步骤或任务的状态。例如,用户可能想要区分“请求的”和“正在处理的”。从批准的角度来看,请求和正在处理都是未批准(打开的)。如果某物从批准返回到未批准(打开),他们可能会称之为“需要审查”-但它仍然没有被批准。

所以你可能想要这样的东西:

当前任务:状态

请求:打开

进程中:打开

需要审阅:打开

批准:批准

随着时间的推移,你的用户可能会想要更多的“模式”或“任务”。如果你为每一个目标设定一个状态,你最终会比你或者他们真正想要的复杂得多。如果你让用户拥有他们想要的尽可能多的“模式”或“任务”,并且与状态有多对一的关系,那么从你的角度来看,它会更简单,但从用户的角度来看,它会更精确。

这是我们经常遇到的,所以我们制作了一个通用的路由系统。这可能是对你正在做的事杀伤力过大,但欢迎你来我的想法。它允许使用链(顺序批准)或星(广播)将任意内容路由到任意用户,并有最小的批准票数。 Here 是架构的自动生成的ERD。

基本上我们有一个包含一个或多个路由方案列表的路由方案。每个列表可以是链或星,整个方案可以作为链或星启动。每个名单和整个计划都可以有自己的投票赞成。这意味着你可以有一个类型为“星”的计划,有两个列表,一个星和一个链。整个方案可以有1票赞成票,因此如果任何一个列表批准,则整个工作流将被批准。链列表可以有与成员数相等的“要批准的投票”,因此每个成员都必须在下一个成员可以投票之前批准,而第一个不批准的成员将终止该列表。在星型列表中,您可以对1投赞成票,这样列表中的任何人都可以立即批准整个工作流

这些方案是无限期保存的,一旦建立,就可以重新使用。为了实现一个方案,路由表中会有一个条目,其中包含方案id、要路由的内容以及一些细节,如批准和不批准文本。然后“routing_u”表存储已实现方案的状态。

我们使用跨应用程序事件系统发送电子邮件,或在路由状态更改时通知其他应用程序。

我现在在一个类似的项目中(不同的平台/db)。

我有一个数据库应用程序,有不同级别的用户权限,他们可以积垢什么类型的记录。在大多数情况下,我在代码中控制允许的操作。

但是,对于许多构造,我有一个构造的“状态码”,然后定义(同样,在代码中)谁可以对该构造做什么,以及他们可以将其移动到什么状态码。