前后端业务枚举映射问题解决方案

前后端业务枚举映射问题解决方案

这个问题其实和我们遇到的时间格式转换类似。

数据库存储业务标识为方便计算或判断，多为 数字 或 字母 ，这类数据在返回给前端做展示的时候，需要转换成对应的业务标识说明，如币种在数据库中可能存储 CNY，实际我们展示的时候，有可能需要将其转成中文 人民币 来进行展示，这时，便有了前后端业务枚举映射的问题。

方案建议

这里我列举一些可行的方案建议，并对其简要说明优缺点，仅供参考

方案一：前端转义

前端负责全部转义职责，解决思路很简单，将所有数据库保存的值直接返回给前端，前端根据上下文对枚举值进行相关的业务说明映射；

示例

如数据库存储数据如下，很简单的拟造数据样例。

数据说明：state 1 表示数据处理成功，state 0 表示数据处理失败

id	state	date
1	1	2021-1-26 10:49:04
2	0	2021-1-26 10:51:33

后端在查询后，将数据结果直接返回给前端，前端在接收到该值后，页面渲染时，将数据进行转义处理，最终结果

id	state	date
1	成功	2021-1-26 10:49:04
2	失败	2021-1-26 10:51:33

优点

• 后端代码无冗余代码，职责清晰，不负责转义相关内容。
• 静态页面可随时更新枚举项映射关系，不需要服务端参与。

缺点

• 前端需维护全部的业务枚举
• 需要前端所使用的框架支持按行渲染，否则需要开发人员自行开发相关渲染转义逻辑。

方案二：通过增加 getStr 转义方法

增加 getStr 方法转义就是根据返回的数值或字母，将其映射后再返回，这步需要增加对应转义 str 字段，前端取该字段做展示即可。当然这步也可将 str 作为数据库字段存储。需根据数据量酌情考虑。

对于前端获取枚举列表的话，可以开发接口将后端使用的枚举映射缓存提供给前端进行使用。前端直接通过本地存储即可，可应对分离开发场景下的独立部署缓存问题。通过直接刷新浏览器本地缓存来解决。

示例

如数据库存储数据如下，很简单的拟造数据样例。

数据说明：state 1 表示数据处理成功，state 0 表示数据处理失败

id	state	date
1	1	2021-1-26 10:49:04
2	0	2021-1-26 10:51:33

实体类写法如下，已省去其他无关代码

private String state;
private String stateStr;

public String getState() {
    return state;
}
public String getStateStr() {
    return cache.get(state);
    return state == 1 ? "成功" : "失败";
}

state == 1 ? "成功" : "失败" 的映射逻辑可通过缓存实现，提高代码整洁性，维护性。

优点：

• 前端不需要参与转义工作，直接获取 str 字段进行展示即可

缺点：

• 需在实体类补充相关代码，并维护好映射关系。

方案三：通过枚举转义

这种方式和 方案二 类似，不过其更加方便维护。这要得益于现在的 ORM 框架的表现。

示例

定义映射枚举类

public enum State {
    SUCCESS(1, "成功"),
    FAIL(0, "失败");
    
    @EnumValue
    private final int value;
    private final String descrip
        
}

实体属性使用枚举类型

public class Obj {
    // 使用定义好的枚举类
    private State state;
}

优点

• 较好的封装性，代码整洁，可读性较高

缺点

• 需要编写大量枚举类
• 需要 ORM 框架的支持