jxTMS设计思想之业务框架

jxTMS是以低成本快速定制为核心诉求的、SaaS模式的二次开发平台,详见:jxTMS简介。本文是讲述jxTMS平台的业务框架是如何设计的,整个系列请访问:jxTMS设计思想

任何软件都随着越来越多的需求的加入,会越来越复杂。jxTMS同样如此。

但jxTMS的核心诉求就是低成本快速定制,而保持简单就是保持低成本的最好办法,所以面对日益复杂的问题,jxTMS的思路是尽可能的将其中通用的功能整理为简单的工具提供给开发者,以此来遏制开发的复杂化趋向。如,用业务规则表来克服合规性检查的复杂化、用兴趣点来遏制业务间衔接的复杂化。

本文所讲述的业务框架同样如此,其要解决的是业务的弹性扩展问题。如,随着业务的扩大与深入,合同会越来越复杂:

  • 结算方式有:货到后见票付款、货到后款到开票、带款提货然后开票、快递代收货款、预收全款后发货再开票、预收部分款后发货再开票、预收全款后开票再发货、预收部分款后开票再发货等等,而这些不同的结算方式就会导致备货-发货-收款-开票的交付作业程序的不同

  • 运输方式有:卖方送货、买方自提、快递、代办货运到站、代办货运到门、空运等等

  • 运费有:产品价格已包含、买方承担、双方按比例承担等等

而这些都是在业务扩展的过程中,通过和各种各样的客户一点点磨合出来的,这是业务系统无法在企业中深入应用的根本原因:无法伴随企业的发展变化而及时的进化来支持企业效率的同步提升。也是jxTMS的核心诉求【低成本快速定制】的由来。

这就对业务系统提出了弹性扩展的问题,即业务出现新变化时:

  • 当前的代码不但依然能用,还不应影响其稳定性、可靠性,即影响范围可控

  • 新增部分不影响原有、现有业务作业、查看,即老业务不受影响

  • 新增部分可以简单的融入原有业务体系、开发量最小化、测试不应大范围扩大,即新增代价小

虽然,我们不可能要求所有业务都能做到上述要求的平滑扩展,但现实中的大部分业务调整也不会剧烈到总是会三番五次的超出原有业务的范围太远。总是在现有业务的基础上做极少的局部修改。

因此,针对这个平滑扩展的常见需求,jxTMS给出的业务框架的解决方案。

业务框架

jxTMS的业务框架指的是对某一业务可以就其业务类型做平滑扩展。如申请作业,可以细分为费用报销申请、预算申请等等。

那么,就可以实现一个称之为申请的业务功能,统一完成所有申请作业的审批流程、表单、数据保存、日志、现场数据、数据变化等全部工作。然后如需增加费用申请,则只需要细化费用明细的处理、费用申请下来如何使用的勾连处理等。

即,业务框架是先完成一个业务总体的处理框架,然后具体的作业类型各自完善自己的细节部分。这样当需要增加一个项目立项申请时,其它都不需要动,只要针对项目立项完善其界面和立项后的逻辑处理就好了。

业务框架本质上就是两个capa之间的协作,其中实现基础功能的叫做主capa,实现细节处理的叫做子capa。

主capa实现基础功能,包括web主界面和一整套行为逻辑。然后:

1、在web界面中,为子capa的扩展保留一个空白的div。如申请的web界面定义中:

//框架中显示各类型的细节
web viewOtherApproveBrief parent approveBrief type div;

其中的approveBrief就是主capa为查看申请而设计的web界面,在approveBrief中为调用子capa所扩展的细节界面而预留一个viewOtherApproveBrief的div。各子capa自己扩展的界面全部都显示在其中。

2、主框架会定义业务操作的完整行为逻辑。然后在细节处理时,为回调子capa保留接口,并约定语义。如创建申请的行为逻辑是:

创建申请的行为逻辑

其中为调用子capa约定了两个接口:一个是显示细节界面的viewApprove操作,一个是提交申请时执行细节处理逻辑的approveActive->newApprove操作。后者会进一步细分是因为还有审批流转过程中的:

  • 拒绝申请时的:approveActive->reject

  • 同意申请时的:approveActive->accept

业务框架的编程

业务框架的编程包括主capa和子capa两部分,通过上面的说明,可以看出主capa比较简单:

  • 定义主体界面,包括基本信息、基本操作等子界面,然后为各子capa预留一个容器来具体装载子capa的细节界面

  • 根据指定的子capa类型,回调子capa来显示该子界面并进行数据装定

  • 设计并实现本业务的业务逻辑,根据此业务逻辑确定主、子capa的交互接口,并在具体的主业务逻辑中,在交互接口处,回调子capa

子capa其实也很简单:

1、在本模块加载时,将本capa所实现的业务类型注册到主capa中

2、定义子界面细节,并实现prepareDisp事件响应函数

3、实现本业务类型在各交互接口处的处理逻辑

那么,在主capa中,如何指定业务类型呢?有两种方式:

1、在创建业务时,需要将已经注册的所有业务类型显示给用户,让用户自己选择

这需要两步,即先在创建业务的prepareDisp事件响应函数中,将所有注册过的业务类型列表给用户,然后在用户点选相应的业务类型后,要显示该类型的子界面并回调其prepareDisp事件响应函数以完成该类型子界面的数据装定。

2、在业务创建后,将用户所选择的业务类型,作为特定参数放入查看详情的入口中,这就需要重载setViewAParam来为getViewA函数生成本业务的查看详情入口时设置参数。如:

#setViewAParam会被getViewA调用,其参数中的a就是getViewA所创建的入口
def setViewAParam(self,a):
    a.setParam('coTitle', self.getInput('coTitle'))

目前jxTMS已经开放个人注册试用,欢迎大家注册试用:

注册到jxTMS

下面的系列文章讲述了如何用jxTMS开发一个实用的业务功能:

如何用jxTMS开发一个功能

下面的系列文章讲述了jxTMS的一些基本功能:

jxTMS的HelloWorld

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值