posts - 176, comments - 240, trackbacks - 0, articles - 7

BizFlow extends CRUD

Posted on 2006-07-15 22:25 canonical 阅读(1434) 评论(5)  编辑  收藏 所属分类: Witrix开发平台

  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概念的一种误读.
 

Feedback

# re: BizFlow extends CRUD  回复  更多评论   

2006-07-17 09:35 by ronghao
很感兴趣,我前段时间的想法和这个比较象,只是放到业务层拦截而已.这个不会是你的一个产品吧?

# re: BizFlow extends CRUD  回复  更多评论   

2006-08-07 23:05 by OneEyeWolf
  你这个东东,其实和workflow是沾不上边的,不知道为什么叫BizFlow.你所描述的业务状态的变化是杂乱的,视具体业务对象属性和商业逻辑操作而定,一般很难设计出驱动对象发生状态变化的事件机制。所以叫BizFlow明显的让人误解。
  如果你和workflow勉强的相比,可能会让你的思路受到影响。

  你上述对业务对象的7条分析,并没有带出你下一步是如何设计来应对这些变化与操作的,看不出具体的思路所在。

  实际项目复杂的操作并不能分析出这几条而到此为止,要想满足这7条,估计是非常困难的。估计你的只能满足你特定领域的一些简单的操作。

  个人觉得设计应当分享具体的职责,这样可以复用,同时隔离变化
  实体描述器(descriptor):对实体对象的一个描述,
  操作器(Operator):具体操作器的实现分为:creator, deletor, saveOrUpdator, updator等几种实现。
  查询器:实现对实体的简单与复杂的关联查询。 

  导航器:实现对实体的业务操作后,发生的具体跳转。
验证器(Validator): 实现对业务数据的验证
权限认证器(Authencator):实现权限的判断




 
  
  
  

# re: BizFlow extends CRUD  回复  更多评论   

2006-08-07 23:21 by canonical
@OneEyeWolf
具体实现的策略就是 CRUD + Filter, 我已经写得非常清楚.

我们的bizflow实现是基于tpl技术的,而不是使用operator的概念, 那样太受局限了。

bizflow是由biz object 驱动的流转,而不是由步骤的先后顺序驱动的流转,所以它不是完整的工作流。

简单的bizflow可以满足众多不需要分支的流转需求,这已经足够做一些有意义的事情。

对于事件机制不是设计而是描述。

# re: BizFlow extends CRUD  回复  更多评论   

2006-08-07 23:32 by OneEyeWolf
基于接口定义不代表就不能基于TPL,如果你的东东做放出来做为组件的话,就必须留有可扩展的余地。
  你也很清楚,只有配置文件,并不能解决所有的问题。

  虽然你的思路是对的,作为应用只需要二、八开就足够了,即只需要满足80%的需求,就已经大大降低了开发人员的工作量。

  但作为框架或组件的思想,远远不在于此,而在于可扩展。

# re: BizFlow extends CRUD  回复  更多评论   

2006-08-07 23:43 by canonical
@OneEyeWolf
如果你有兴趣, 应该读一读我其他的文章, 以搞清楚我在说些什么.
http://canonical.blogdriver.com/canonical/961298.html

operator的设计正在于它的可扩展性不够.

只有注册用户登录后才能发表评论。


网站导航: