系统设计 | 数据字典方案
文 | 少个分号 (转载请注明出处)
公众号:DDD 和微服务
知乎:少个分号
微信号:shaogefenhao
网站:shaogefenhao.com
问题分析
在应用项目中,我们总会遇到很多字典项的数据,比如类型、状态等。这些数据一般是有限个可选值,在前端可能作为 Select 控件存在,用于录入、搜索等场景。
这类数据的一般作为配置存在,怎么设计才能让前后端维护方式最低呢?
我们在团队上做了很多讨论,结合过完项目的经验把潜在方案整理如下。
方案枚举
假定我们经过简单的头脑风暴,可以枚举出下面的方案,再来分析其优缺点:
直接硬编码,前端编码到 Select 控件中,后端在代码中作为字符串出现
统一管理到数据库,并通过 API 输出给前端
放到配置中心的 YAML 文件中,并通过 API 输出给前端
放到 Redis 中,并通过 API 输出给前端
后端使用枚举,并通过 API 输出给前端
经过比较我整理了一份对比表格:
在实践的经验中,以上几种方案都见到过,在选择技术方案时遵守几个原则:
先方案枚举,避免先入为主
抓主要矛盾,剔除干扰
结合性价比,实用优先
比较下来,放到数据库的实践设计过重,因为几乎用不到需要在线变更字典的情况。而放到配置中心是一种中庸的方案,既可以灵活调整维护成本也并不高。
而 Redis 的这种方案看不到特别的优点,在很多公司也不合规。
使用枚举类直接替代字符串的数据字典维护成本低,因为服务端开发本身就需要使用枚举值,这样不需要再次和字符数据字典映射。
基于枚举类的方案还可以进一步优化,通过注解标出需要作为数据字典的枚举类,或者继承一个父类,通过反射扫描出系统所有的数据字典项,并通过 API 输出给前端使用。
参考实现
当分析出这些技术方案后,我把这个扫描枚举类的实现方式发送给 ChatGPT,得到了一个比较满意的 Demo,经过修改就可以用到项目上了。
参考资料
https://cloud.tencent.com/developer/article/1032868
https://bbs.huaweicloud.com/blogs/346461
https://www.finclip.com/news/f/13948.html
版权声明: 本文为 InfoQ 作者【少个分号】的原创文章。
原文链接:【http://xie.infoq.cn/article/641f45bba8a23564c397a9543】。文章转载请联系作者。
评论