BizFlow extends CRUD

  CRUD(Create Read Update Delete)是一般应用程序中最基础的操作，但是用户的需求却很难直接映射到CRUD操作上。例如常见的需求如下:
 1. 不同的业务处理处于不同状态的业务对象:
     业务A处理状态为X的业务对象,而业务B处理状态为Y的业务对象
 2. 业务对象处于不同状态的时候允许的操作不同:
    状态处于X的业务对象允许操作U, 而状态处于Y的业务对象允许操作V
 3. 不同的业务操作可能修改业务对象的不同属性:
     操作U修改业务对象的属性P, 操作V修改业务对象的属性Q
 4. 具有不同权限的人能够从事的业务不同:
      角色R处理业务A, 角色S处理业务B
 5. 具有不同权限的人即使从事同一业务,所能够操作的业务对象集合也不同:
     角色R处理部门M的业务对象,角色S处理部门N的业务对象.
 6. 具有不同权限的人即使可以操作同一业务对象,所能够采取的业务操作也不同:
      角色R只能进行操作U, 角色S只能进行操作V
 7. 在业务对象上执行操作之后可能造成状态变迁:
      处于状态X的业务对象上执行操作U后状态变为Y

以上这些需求往往是系统中最易变的部分, 而它们在概念上恰恰表现为对CRUD的一种限制性描述. 因此通过如下扩展我们可以定义BizFlow的概念: BizFlow = CRUD + Filter. 根据这种观念, witrix平台中BizFlow被实现为DaoWebAction的一种无缝扩展.
   在jsplet框架中我们通过如下url模式来访问后台的CRUD操作:
   /list.jsp?objectName=MyObj&objectEvent=Query
为了实现BizFlow只需通过spring为DaoWebAction配置一个xml配置文件, 此后仍然可以通过
    /list.jsp?objectName=MyObj&objectEvent=Query
来访问后台的CRUD操作,只是后台会自动应用配置文件中的 bizId="default", bizActionId="Query-default"等配置项.
如果我们采用如下url来访问
    /list.jsp?objectName=MyObj&objectEvent=Query&$bizId=test&$bizActionId=test   
则后台将应用配置项 bizId=manage, bizActionId=Query-test, 而
    /list.jsp?objectName=MyObj&objectEvent=BizAction&$bizId=test&$bizActionId=test   
则对应于配置项 bizId=manage, bizActionId=BizAction-test.
   应用BizFlow配置项之后,所有前台代码都可以不做出任何改变, 因为它们只是对于给定数据的展现.
  
   BizFlow可以看作是CRUD加上简单的流程控制和权限控制所构成, 但是它与完整的工作流模型还是有着显著区别的. 工作流中所关注的重点首先是流程实例而不是业务对象实例, 在一个流程中是否存在唯一的业务对象,以及业务对象的状态是否随着流程流转发生变化完全是一件独立的事情,它们并不属于抽象的工作流模型本身. 理论上说,一个业务对象可以同时参与多个流程. 在工作流建模中主要通过流程步骤的先后顺序的约束来描述业务进程, 处于同一状态的业务对象可能处在不同的流程步骤中. 而BizFlow可以看作是状态驱动的, 当前业务步骤直接由业务对象的状态决定. 在BizFlow中因为视角是业务对象的状态,因此我们直接面对的是大量处于同一状态的不同的业务处理过程, 而workflow中往往建模的时候强调单流程实例视角,而一般缺乏对于流程实例相关性的描述. 现在国内很多人认为工作流就是状态机其实是对workflow概念的一种误读.