大家怎么看待数据字典，你们的项目里引入数据字典了吗

[sma11hao]

[dqzcwxb]

你是不是想说配置中心?

[route]

有用，在我看来就是常用的枚举

[devswork]

不光有，还得用户能在后台自己配置新增条目、删除条目，比如一些分类、单位，配置后可以返回给前端，用作单选、多选什么的，很常用

[sma11hao]

@dqzcwxb 不是，就是业务枚举居多，比如订单状态，然后客户端也都从服务端拿枚举数据

[defunct9]

不懂就问，大家有什么好的数据字典、配置中心软件推荐

[sma11hao]

对各端来说感觉开发是简便了，想问问大家会不会有其它问题？然后各个系统间你们是维护到同一个地方的吗

[dqzcwxb]

@sma11hao #4
简单做法:写数据库用 redis 做缓存或者直接写 redis hash 里去
进阶做法:配置中心

[PEax]

有，我们这边是有一个技术中台，专门配置权限，字典这些。然后前端项目登录的时候引入值集并缓存，同时挂载到 window 上，一般都用在下拉选项啥的。挺方便的（产品自己配值集，可以减少前后端工作量，而且不容易出问题）

[PEax]

@PEax 忘记说了，使用的框架是 hzero

[treeAgain]

@PEax 我们这边之前也让这么做，但是我拒绝了，从前端层面来说，配置的字典在下拉框里可以，但是一般不会只是在下拉框里，有很多逻辑判断，比如 在某个状态需要做业务处理，那但凡有这种的就不好使了，前端依然需要自己做字典映射，工作并无减少，还增加了接口去做缓存

[hhjswf]

@PEax 不懂就问，有什么必要嘛，就不能上个缓存简单的从字典表读吗

[lscho]

@treeAgain 前端当然要接口获取字典了，我觉得工作量并没有增加，因为多写一个接口就不用维护字典了。而且字典本来就是要放在后台管理的，总不能字典变化了，前端再同步发个版吧。

[dfkjgklfdjg]

@lscho #12 ，一些特殊业务逻辑判断的时候确实要同步重新发版。但是字典值规范好的话基本上不用这样做。

[javlib]

以前公司有个自己开发的，技术上也很简洁
- 每个配置项用一个 java bean 表示
- 存储以 json 方式存数据库
- client 通过配置名 + 版本取数据
- admin 端通过 java bean 生成一个简单的 crud 页面

这个配置系统大部份是产品运营的人在用，比如活动页面的图片，字段变更之类的。

缺点就是新增配置项要增加一个 java bean ，否则 admin 页面看不到新配置项的 crud

[wqhui]

对于一些经常需要增加的选项值来讲还不错，如果只是起标签作用的枚举不用发版就能解决了，但如果对于一开始就能基本确定所有状态的枚举来说没必要。前后端肯定是通过接口来获取的，前端对字典的存在无感知，后端不同服务之间可以直接共享字典，或者更好一点的做法是每个服务维护自己的字典，然后也是走接口获取其它服务的字典内容

[sma11hao]

看来大家用到的居多，只是做大做小的区别，感谢大家分享。

[tairan2006]

准确来说是：修改枚举不需要修改代码的时候会用。

有的枚举严格对应逻辑，这种写代码里都行。

[lizy0329]

数据字典，能说出这个东西的程序员至少在 40 岁以上

[devswork]

@lizy0329 #18 我是 90 后

[infun]

开源的 阿波罗
https://github.com/apolloconfig