金蝶BOS元模型分析

对一些需求变化多样的产品而言，做好可变性设计是非常重要的。国外做得好的有Siebel，国内有金蝶的BOS，实际上金蝶的BOS很多理念跟Siebel是相似的，呵呵。。。他们都是采用MDD的方式来解决可变性问题的。

这里的难点在于如何抽象出一套稳定的元模型，能描述各种各样的变化，以达到通过配置即可搞定需求变更的目的。

这里着重讲一下金蝶BOS的元模型，所谓元模型，是模型的模型。

在数据层，有Table，Table对应到数据库表，直接三种Table之间的关系，什么交叉表、扩展表之类的，基本与平常大家设计表的范式对应，不多说；

在业务逻辑层，有实体，实体表示系统的领域实体对象，一个实体对应到一个Table，实体的属性对应到Table的field或其扩展表的Field，实体与实体之间有关系，关系分为One2One，One2Many，Many2One，Many2Many。还可以对实体的属性定义计算公式，约束。但缺乏实体级别的约束。我认为金蝶可以增加这一个小特性：）。实体可继承另一个实体，以获得另一个实体的定义。

可以为实体定义方法，方法映射到一个规则。也就是说调用这个方法的时候实际执行的是这个规则；

可以为实体定义查询方案、过滤方案、排序方案，主要是以OO的方式做实体查询，对外暴露OO化的用户接口，对内生成SQL用；

可以为实体定义事件，Function和Facade可监听事件，事件由Function触发。

金蝶对Function的解释是“业务功能是对运行系统的Entity对象、UI对象及其方法的一定封装，供其它模块或二次开发使用”，比如上文提到的事件，即是由Function触发的，但不知为什么还要指定事件的方法，Function是事件的生产者，事件的方法表示事件的消费者（监听者），这样做不是导致生产者与消费者耦合了吗？？那还要事件干什么，不知道有没有朋友能解答这个问题？？Function还可以绑定到一个UI的Action，意味着当该UI对象的Action触发时，会执行这个Function。对UI Action的绑定是可选的。

Facade表示领域Service对象，相比实体，其仅仅有方法，没有属性。

UI对象表示一个界面对象，比如订单创建对象，可以对其指定Layout，UI对象支持绑定实体、Query对象。UI对象也有事件、Action和状态，事件和Action应该可以绑定到Function和Facade，State表示界面对象的状态，比如界面通常有编辑状态、查看状态等等。UI对象还有个父对象，还没怎么弄清楚UI对象与UI对象之间的关系，没有看到描述，需要进一步研究；感觉BOS对UI层的抽象略显简单，通常UI层是最复杂的，有字段联动，子页面联动等等，没见到BOS怎么来搞定这种联动场景。

 

查询表示对对象的查询，需要绑定一个对象树，可定义查询方案、过滤方案、排序方案，生成SQL用；

还有其它的一些非主要元模型。

通过UI Object、Entity/Function/Facade、和Table，可支持描述界面、领域对象/服务、数据库表以及它们之间的绑定关系，如果对象模型有变更、或者业务逻辑有变更，会导致这三层的对象的变化，而变化可基于这三层的元模型描述，实现配置即可用。