一．目标
“原型系统+规则库=行业软件”
二．构成
- 自定义表单
- 自定义规则
- 自定义流程
- 自定义报表
- 自定义打印
三．详述
- 1. 表单
应该可以进行表单界面的可视化设计，设计的表单具有基础的增删改查等功能，对于增删改查等权限划分规划到规则设计中来配合实现。
表单设计中应该要包含一套基础控件库，控件可以绑定表对象，数据对象，函数对象，规则，并可以根据数据对象的权限对应不同的状态，比如是否可读，可写等权限。
- 2. 规则
将规则从系统中抽取出来意义重大，在一个系统中业务规则占据了相当大的比例，而且是变动最为频繁的，我们总是希望把容易变动的和不容易变动的分离开来，这样就不至于因为修改易变的部分影响不需变的部分，从而简化系统修改的复杂性，也提高系统的灵活性。
业务逻辑从本质上来讲就是一种规则的集合，数据和展示都是规则实施的对象，规则甚至也可以对规则起作用，这样就成了规则的规则。因此如果要设计规则引擎那么这个规则必须要可以引用和操作数据（水平，垂直），页面，控件，规则等组成部分。
规则大部分是“如果-那么”这种形式，这种形式从本质上讲可以看做“条件-执行”，这样所有的规则都拆分为规则条件和规则执行体两部分。规则有作用域，顺序，黑名单，白名单，例外等。
规则是在配置文件中的，可方便修改而不用修改程序和进行编译，也可以缓存起来以提高性能。
规则的管理可以通过设计一个规则表格，方便设计和进行规则查询，如果能实现一个规则表格设计器可以大大方便规则的制定，降低规则学习的门槛。
因为要保证规则的全局性，那么对所有的数据对象访问, 方法调用都要经过这个规则校验，因此需要一个集中的入口或者出口，所有对数据的访问和方法的调用都要有个用户id，规则引擎根据id和规则库来校验操作的合法性。
引入规则引擎对开发模式影响也是很大的，由于业务规则从系统中分离出来，数据的基本操作都可以变成简单的增删改，有利于程序自动统一处理。开发的重点变成了开发规则执行的规则，简单的说就是制定规则的规则。系统初始化后只有一个设计器，通过设计器建立行业模型，再通过设计器对模型进行规则限制，这些工作将转移到实施部门进行，不需要开发部门进行干预。
由于建立一套行业规则的工作量是很大的，因此可以预置几套行业规则模板，同一套系统在不同的规则下来适应不同的行业业务。
- 3. 流程
工作流是OA系统的一个核心功能,我们已经有一套可行的工作流，但是有些功能还是需要完善。可以先描述一下我心目中理想的工作流，工作流的设计应该是独立于表单的，在一个工作流中各节点可以根据需要挂接不同的页面，而不是向我们系统那样一个流程只能有一个页面。流程的执行条件和动作依赖与规则，在原型系统中规则引擎的建立是一个基础性工作，属于微观操作，工作流的设计属于宏观操作，但是工作流引擎的工作依赖与规则引擎来进行条件判断和动作执行。
4 . 报表
我们的系统现在也有不少的报表，但是报表很不通用，实现起来工作量也很大，因为要为不同的模块根据功能实现不同的报表。应该制作一个通用报表功能模块，报表模块可以引用任意相关联的业务数据，根据关联对数据进行统计分析。对于常见的报表可以让客户自己选择要统计分类的列和统计汇总（求和，平均值，最大值，最小值，计数）的列。
要做到这一点有几个要求，一是要有统一的字典表，现在系统中字典表的数量不下10个，对于自定义报表关联难度大大增加了。对于用到的数据表需要有一个类似TableList和FieldList的表对表中的字段做出中文，英文等说明当做自定义报表的表头用。
5 打印
需要现在的打印的基础上可以关联报表中的数据作为数据源，这样打印的应用范围就大大增加了。
朱现国 2014-07-25