问题###
在很多业务应用中,往往有很多文案及按钮的业务逻辑,很容易因为产品的策略变更而变化,或因为来了新业务而新增条件判断,或因为不同业务的差异性而有所不同。如果通过代码来实现,通常要写一串if-elseif-elseif-else语句,且后续修改扩展比较容易出错,需要重新发布,灵活性差。 可采用配置化的方法来实现按钮逻辑,从而在需要修改的时候只要变更配置即可。业务逻辑的代码形式一般是:
public Boolean getIsAllowBuyAgain() {
if (ConditionA) {
return BoolA;
}
if (ConditionB) {
return BoolB;
}
if (CondtionC && !CondtionD && (ConditionE not in [v1,v2])) {
return BoolC;
}
return BoolD;
}
本文讨论了三种可选方案: 重量级的Groovy脚本方案、轻量级的规则引擎方案、超轻量级的条件匹配表达式方案。
方案###
Groovy脚本####
需要在界面上进行编辑和及时刷新到应用中的代码,可以使用 Groovy 脚本来替代。
可参阅:“使用yaml+groovy实现Java代码可配置化”
规则引擎####
多样化可变的业务逻辑和规则集合非常相似,可以考虑采用一款轻量级的规则引擎。通过配置平台来管理规则集合。
使用规则引擎的示例可参阅: “Java Drools5.1 规则流基础【示例】(上)”
可选用一款轻量级的Java开源规则引擎作为起点。
条件表达式####
对于轻量级判断逻辑,采用条件表达匹配。条件表达匹配,实质是规则引擎的超轻量级实现。
条件表达式方案可参阅:“详情文案的轻量级表达式配置方案”
选择###
三种方案的对比如下:
方案 | 灵活性 | 性能 | 易懂性 | 适用场景 |
---|---|---|---|---|
Groovy 脚本 | 极高,凡是代码解决都能用Groovy脚本解决 | 需要缓存,几十到几百毫秒 | 业务人员不易读懂 | 代码配置化,方便技术人员使用 |
规则引擎 | 较高 | 几十毫秒 | 适合业务人员读懂 | 大量规则和推理,规则之间有关联 |
条件表达式 | 特定 | 几到几十毫秒 | 适合业务人员读懂 | 少量复合条件,相互独立 |