问题分析
在应用项目中,我们总会遇到很多字典项的数据,比如类型、状态等。这些数据一般是有限个可选值,在前端可能作为 Select 控件存在,用于录入、搜索等场景。
这类数据的一般作为配置存在,怎么设计才能让前后端维护方式最低呢?
我们在团队上做了很多讨论,结合过完项目的经验把潜在方案整理如下。
方案枚举
假定我们经过简单的头脑风暴,可以枚举出下面的方案,再来分析其优缺点:
- 直接硬编码,前端编码到 Select 控件中,后端在代码中作为字符串出现
- 统一管理到数据库,并通过 API 输出给前端
- 放到配置中心的 YAML 文件中,并通过 API 输出给前端
- 放到 Redis 中,并通过 API 输出给前端
- 后端使用枚举,并通过 API 输出给前端
经过比较我整理了一份对比表格:
优点 | 缺点 | |
---|---|---|
硬编码 | 简单粗暴,不需要特别设计 | 维护困难,容易造成前后端枚举值不一致 |
数据库 | 灵活修改,可以不发布、不重启修改配置 | 维护困难,需要考虑每个环境的数据值 |
配置中心 | 维护简单,灵活修改,可以不重启修改配置 | 没有特别的缺点 |
Redis | 和数据库类似 | 维护困难,数据容易丢失 |
枚举类 | 简单,代码中本来也就需要使用枚举值 | 需要发布服务才能使用,枚举类可能过长 |
在实践的经验中,以上几种方案都见到过,在选择技术方案时遵守几个原则:
- 先方案枚举,避免先入为主
- 抓主要矛盾,剔除干扰
- 结合性价比,实用优先
比较下来,放到数据库的实践设计过重,因为几乎用不到需要在线变更字典的情况。而放到配置中心是一种中庸的方案,既可以灵活调整维护成本也并不高。
而 Redis 的这种方案看不到特别的优点,在很多公司也不合规。
使用枚举类直接替代字符串的数据字典维护成本低,因为服务端开发本身就需要使用枚举值,这样不需要再次和字符数据字典映射。
基于枚举类的方案还可以进一步优化,通过注解标出需要作为数据字典的枚举类,或者继承一个父类,通过反射扫描出系统所有的数据字典项,并通过 API 输出给前端使用。
参考实现
当分析出这些技术方案后,我把这个扫描枚举类的实现方式发送给 ChatGPT,得到了一个比较满意的 Demo,经过修改就可以用到项目上了。
@RestController
@RequestMapping("/enums")
public class EnumController {
@GetMapping
public List<String> getEnums() {
List<String> result = new ArrayList<>();
try {
// 扫描项目中的所有类
Reflections reflections = new Reflections("com.example");
Set<Class<?>> classes = reflections.getTypesAnnotatedWith(MyAnnotation.class);
for (Class<?> clazz : classes) {
// 找到实现了 MyInterface 接口的类
if (MyInterface.class.isAssignableFrom(clazz)) {
// 获取类的所有内部枚举类型
Class<?>[] innerClasses = clazz.getDeclaredClasses();
for (Class<?> innerClass : innerClasses) {
// 检查枚举类型是否实现了 MyInterface 接口
if (innerClass.isEnum() && MyInterface.class.isAssignableFrom(innerClass)) {
// 将枚举类型的信息添加到结果列表
result.add(innerClass.getName());
}
}
}
}
} catch (Exception e) {
// 处理异常
}
return result;
}
}
参考资料
- https://cloud.tencent.com/developer/article/1032868
- https://bbs.huaweicloud.com/blogs/346461
- https://www.finclip.com/news/f/13948.html
文 | 少个分号 (转载请注明出处)
关注公众号:DDD和微服务
微信号:shaogefenhao
同名知乎:少个分号
本文仅供学习!所有权归属原作者。侵删!文章来源: DDD和微服务 -少个分号 :http://mp.weixin.qq.com/s?__biz=MzA4Mzc2MzcyMQ==&mid=2247484508&idx=1&sn=74fe305a30e0e924a1cabbe96c1d0a5f&chksm=9ff0333aa887ba2c2c5dff913a06088dc840f2fca5d48b9d2e9172a7d4d10cc6b627d2583147&scene=21#wechat_redirect
文章评论