“思考得少,瞎干得多”,就是目前企业开发的现状。瞎干了两个月后,回头来分析一下一个有趣的流程,是我们目前项目中最复杂的一个流程(因为要完成它而不能动脑,所以复杂)。
首先把UML书上的案例扔到一边,那个是齐全的菜谱、佐料、原料而真实项目是荒地。想想走到荒地上给自己整一顿满汉全席,不容易啊…… 现在已经忘了最初听到这个流程的描述是怎么样的了。大概就是“一个待办项会发送和接收很多次,也可以发送接收一次,发送完后就不能再次发送了,最后一个接收结束后才能结束整个流程”——够昏的吧^O^遇到这种事千万不能听客户、需求人员甚至项目经理的,架构师才是设计这个系统的人,不能自己分析、定义业务对象,下课去吧。
第一反应就是发送和接收必须是两个不同的待办项,随后是必须定义两个不同的动作:完全发送和部分发送。概念一定要区分准确。 随后关于如何叫完全发送和部分发送有几次需求上的变化,但不影响流程的执行规则。
这个就形成了我在业务流程配置一文中写的ResponseTask类,当时的需求就是请求-接收,所以只写了两个Task;随后扩展成了每接收之后还有一个任务叫填写意见书,所有的意见书完成之后再开始一个新的任务。所以就改成了:请求-接收-响应三个操作,修改ResponseTask,增加了ResponseType这一枚举值属性,修改了结束的算法。目前的流程执行规则是相当死板的,完全硬编码在引擎内部,无法改变。以下是ResponseTask类和执行代码:
using System;
using System.Collections.Generic;
using System.Xml.Serialization;
namespace Microsoft.Applications.ChinaMobilePMS.FlowEngine
{
public class ResponseTask : TaskBase, IComparable<ResponseTask>
{
private int requestNumber = 0;
private ResponseType responseMode = ResponseType.Request;
[XmlAttribute("RequestNumber")]
public int RequestNumber
{
get { return requestNumber; }
set { requestNumber = value; }
}
[XmlAttribute("Mode")]
public ResponseType ResponseMode
{
get { return responseMode; }
set { responseMode = value; }
}
#region IComparable<ResponseTask> Members