EEPlat 的 后台业务处理模型

后台处理包含数据处理、业务逻辑及业务流程等服务端操作的部分。相关的元模型包括业务对象元模型、业务对象属性元模型、服务元模型、参数元模型、业务规则元模型、工作流元模型。如下图所示：

业务对象是业务数据和逻辑的抽象。在一般的实现上它通常对应数据库中的一张表，也可以表示更大或更小的业务范围，例如一个独立的业务模块（销售模块），一张表可以拥有多个业务对象，一个业务对象也可以包含多张表。业务对象通过服务和数据总线完成业务逻辑。

数据总线是业务对象之间共享数据、交换数据的媒介。数据总线是线程独享的、线程安全的，一个线程对数据总线的改变不会影响到其他线程对数据总线的使用，每个线程都是使用的总线的副本。

属性指业务对象所拥有的属性。对于类型为基本表的业务对象，属性基本是相应表的列名。但是属性可以不对应列，列也可以不对应属性。属性可以是一个集合，如果为属性定义一个查询服务，属性对应的是该服务执行返回的集合。这种情况下一般用于处理业务对象之间一对多或多对多的情形。

服务是描述业务对象的行为。当一个数据表被初始化为业务对象后，会形成多个基本的服务，包括了常用的增删改查等常见数据操作。服务的主体是一个增删改查的SQL语句和参数关联，可以修改这些SQL语句和参数关联达到个性化的目的。例如更改数据的状态，我们可以创建一个新的服务或修改缺省的服务，只更改该状态字段的值。服务可以通过规则引用一个或多个其它的服务。

参数的作用主要是从业务对象总线上获取对应的值。参数一般会关联属性，表格元素一般也会关联属性，表格元素被提交后存储于业务对象总线上FORM节点上，参数根据关联属性从数据总线中取值，如果没有关联属性或根据关联属性没有取到值，则根据参数名称取值。

参数检查是指当服务执行操作前先检查服务对应的参数是否合法，如果不合法则不执行。参数检查可以自定义计算表达式、正则表达式、扩展脚本等。参数检查定义在参数上面，可以被多个服务所复用。

规则是为了完成复杂的业务逻辑而引入的概念。 规则的主体是定义一个有执行条件的服务，也就是只有当满足条件时才会执行相应的服务。规则有执行优先级，当多个规则执行时，优先级越高执行的顺序越靠前。

工作流可以使业务流程自动化，工作流主要通过转移由节点组成。 工作流的启动，节点任务的提交和回退都是有服务触发，节点的执行也可以触发服务，这些服务可以是数据表的更改、业务逻辑的执行或者是发送EMail或SMS信息。