写点什么

系统设计 | 数据字典方案

作者:少个分号
  • 2023-09-03
    上海
  • 本文字数:1392 字

    阅读完需:约 5 分钟

文 | 少个分号 (转载请注明出处)

公众号:DDD 和微服务

知乎:少个分号

微信号:shaogefenhao

网站:shaogefenhao.com


问题分析

在应用项目中,我们总会遇到很多字典项的数据,比如类型、状态等。这些数据一般是有限个可选值,在前端可能作为 Select 控件存在,用于录入、搜索等场景。


这类数据的一般作为配置存在,怎么设计才能让前后端维护方式最低呢?


我们在团队上做了很多讨论,结合过完项目的经验把潜在方案整理如下。

方案枚举

假定我们经过简单的头脑风暴,可以枚举出下面的方案,再来分析其优缺点:


  • 直接硬编码,前端编码到 Select 控件中,后端在代码中作为字符串出现

  • 统一管理到数据库,并通过 API 输出给前端

  • 放到配置中心的 YAML 文件中,并通过 API 输出给前端

  • 放到 Redis 中,并通过 API 输出给前端

  • 后端使用枚举,并通过 API 输出给前端


经过比较我整理了一份对比表格:



在实践的经验中,以上几种方案都见到过,在选择技术方案时遵守几个原则:


  • 先方案枚举,避免先入为主

  • 抓主要矛盾,剔除干扰

  • 结合性价比,实用优先


比较下来,放到数据库的实践设计过重,因为几乎用不到需要在线变更字典的情况。而放到配置中心是一种中庸的方案,既可以灵活调整维护成本也并不高。


而 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

发布于: 刚刚阅读数: 3
用户头像

少个分号

关注

还未添加个人签名 2019-09-26 加入

还未添加个人简介

评论

发布
暂无评论
系统设计 | 数据字典方案_系统设计_少个分号_InfoQ写作社区