这是一个创建于 641 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
dqzcwxb 2023-02-07 11:13:08 +08:00
你是不是想说配置中心?
|
 |
2
route 2023-02-07 11:17:29 +08:00
有用，在我看来就是常用的枚举
|
 |
3
devswork 2023-02-07 11:21:24 +08:00
不光有，还得用户能在后台自己配置新增条目、删除条目，比如一些分类、单位，配置后可以返回给前端，用作单选、多选什么的，很常用
|
 |
5
defunct9 2023-02-07 11:24:21 +08:00
不懂就问，大家有什么好的数据字典、配置中心软件推荐
|
 |
6
sma11hao OP 对各端来说感觉开发是简便了，想问问大家会不会有其它问题？然后各个系统间你们是维护到同一个地方的吗
|
 |
8
PEax 2023-02-07 11:33:53 +08:00
有，我们这边是有一个技术中台，专门配置权限，字典这些。然后前端项目登录的时候引入值集并缓存，同时挂载到 window 上，一般都用在下拉选项啥的。挺方便的（产品自己配值集，可以减少前后端工作量，而且不容易出问题）
|
 |
10
treeAgain 2023-02-07 11:43:28 +08:00
@PEax 我们这边之前也让这么做，但是我拒绝了，从前端层面来说，配置的字典在下拉框里可以，但是一般不会只是在下拉框里，有很多逻辑判断，比如 在某个状态需要做业务处理，那但凡有这种的就不好使了，前端依然需要自己做字典映射，工作并无减少，还增加了接口去做缓存
|
 |
12
lscho 2023-02-07 12:54:45 +08:00 via iPhone
@treeAgain 前端当然要接口获取字典了，我觉得工作量并没有增加，因为多写一个接口就不用维护字典了。而且字典本来就是要放在后台管理的，总不能字典变化了，前端再同步发个版吧。
|
 |
13
dfkjgklfdjg 2023-02-07 13:03:48 +08:00
@lscho #12 ，一些特殊业务逻辑判断的时候确实要同步重新发版。但是字典值规范好的话基本上不用这样做。
|
 |
14
javlib 2023-02-07 13:22:23 +08:00
以前公司有个自己开发的，技术上也很简洁
- 每个配置项用一个 java bean 表示 - 存储以 json 方式存数据库 - client 通过配置名 + 版本取数据 - admin 端通过 java bean 生成一个简单的 crud 页面 这个配置系统大部份是产品运营的人在用，比如活动页面的图片，字段变更之类的。 缺点就是新增配置项要增加一个 java bean ，否则 admin 页面看不到新配置项的 crud |
 |
15
wqhui 2023-02-07 14:29:24 +08:00
对于一些经常需要增加的选项值来讲还不错，如果只是起标签作用的枚举不用发版就能解决了，但如果对于一开始就能基本确定所有状态的枚举来说没必要。前后端肯定是通过接口来获取的，前端对字典的存在无感知，后端不同服务之间可以直接共享字典，或者更好一点的做法是每个服务维护自己的字典，然后也是走接口获取其它服务的字典内容
|
|
16
sma11hao OP 看来大家用到的居多，只是做大做小的区别，感谢大家分享。
|
 |
17
tairan2006 2023-02-07 16:35:54 +08:00
准确来说是：修改枚举不需要修改代码的时候会用。
有的枚举严格对应逻辑，这种写代码里都行。 |
 |
18
lizy0329 2023-02-07 17:01:25 +08:00
数据字典，能说出这个东西的程序员至少在 40 岁以上
|
 |
20
infun 2023-02-07 17:11:19 +08:00
|
 |
22
james2013 2023-02-07 17:16:56 +08:00  1
有的,很方便,避免字典值增删导致前后端发版,也避免了前端手写名称和值可能产生的问题
数据库专门有表记录字典名称和值,提供 1 个字典接口给前端查询 前端根据这个接口进行查询和展示 如果某个字典要增加或者减少 1 个值,前后端代码都不需要改,只需要在表里增加或者删除该值就可以了 |
 |
24
litchinn 2023-02-07 17:32:30 +08:00
动态的都应该走数据字典呀，避免由于产品在这些东西上的改动导致要重新编码部署，这和使用动态的路由菜单我觉得是一个道理。
但是楼上说的有逻辑处理的时候，比如要 switch 判断的时候，还是得写个枚举，在这一点上确实没啥好办法(也有可能我目前还没了解到更优秀的设计)。但是枚举的话最好也是前端从后端获取，这样改动的时候后端改就行了，减少工作和 BUG 。 OP 说到的多个系统直接同步的问题，这个好像也只有靠规范了 |
 |
25
Bingchunmoli 2023-02-07 18:47:47 +08:00 via Android
@lizy0329 入门使用 ruoyi 就知道这东西了
|
 |
26
nothingistrue 2023-02-07 19:33:53 +08:00
这东西的重点不是用不用，而是如何管理。不管你用数据库+界面配置字典，还是常量配置字典，还是专用工具配置字典，一旦不妥善管理，一段时间后都不如手写键值对方便。
通常，有 UI 的，code-name 键值对的场景是非常常见的，用数据字典统一管理会更方便点，当然具体上还要看你的需求。“数据字典+后台只保存 code”的好处是便于全局统一管理，但是跟业务的贴合度不一定好，尤其是到了一个 code 不止有 name ，还有其他属性的时候。另外对于静态数据，用硬编码的枚举会更好。 |
 |
27
soupu626 2023-02-07 20:18:48 +08:00
以前看过某 ERP 系统，数据库都是大宽表，搞元数据甚至元元数据，实际存储的字段都是 column+数字编号这种命名
|
 |
28
invisibleUser 2023-02-07 20:24:28 +08:00
@PEax 不太明白，比如下拉接口我需要显示{0:'未选择';1:'男';2:'女'}；列表我需要显示:{0:'-';1:'男';2:'女'}；这种 0 下标有差异化不还是要前端自己去判断吗，这种情况后端该如何返回
|
 |
29
xuanbg 2023-02-07 22:35:13 +08:00
只做业务数据字典。做在公共基础数据中台里面，有个界面交给业务自己维护。
|
|
30
treeAgain 2023-02-08 10:41:48 +08:00
@lscho 事实是 确实是字典变化，前后端需要同步发版，看了一下帖子，基本都是站在服务端视角去评论的，认为只要给了字典数据就可以，事实是前端不只是下拉框的展示，也有逻辑业务
我就举个简答的例子：给了 {0: ‘未完成’，1: ’已完成‘，2: ‘已取消’} 1. 假如现在要加个 {3: '超时完成'},前端根据这个 3 去做展示或隐藏，你说需不需要发版 2. 假如现在 0 变成了 超时未完成，那这个前端需不需要发版 |
 |
31
mynameislihua 2023-02-08 10:48:46 +08:00
@PEax 汉得是吧，我有朋友在那边做前端
|
Select Language