比如接口要传一个请求来源,后端让我传的参是 1 拼多多, 2 淘宝, 3 京东 。。。
为什么不能直接给一个字符串 '淘宝',反正都是要 switch case ,这样也很直观.接手别人的项目里一堆 1234 我都不知道传的是什么,也不写个 map,我很难受
101
mostkia 2020-05-15 18:23:13 +08:00 3
应该这样写
{"code":"✓","mesg":"发送成功"} {"code":"✘","mesg":"发送失败"} 手动滑稽 |
102
Airon 2020-05-15 18:24:45 +08:00 1
1.规避传参等字符编码问题
2.方便兼容和后续改动,名字可能修改,但数字没有实际意义 (如 麦当劳 ->金拱门) 3.数据库设计考虑 int 更节省内存 性能好 索引效率更高 4.部分语言不支持字符串 switch-case 感觉各有各的好处吧。 |
105
pushyzheng 2020-05-15 18:32:52 +08:00 1
🐱:淘宝
🐶:京东 🐮:拼多多 |
106
kojirou 2020-05-15 18:37:18 +08:00 1
你们前端是不会用 enum 吗
|
107
l00t 2020-05-15 18:44:47 +08:00
字符串的编码、拼写错误、大小写问题都比数字多啊。
|
108
revalue 2020-05-15 19:01:19 +08:00
从头到尾没看到个好答案。都水过去了,可惜
|
109
cz5424 2020-05-15 19:24:01 +08:00 via iPhone
@revalue 准确的说没有你想要的答案。我就觉得他们说得在理。不过也是分情况的,返回字符串主要是方便展示,存储肯定是 int 方便,如果字符串万年不改,前端去 map 也无所谓
|
112
shiny 2020-05-15 19:57:59 +08:00 1
你们大多数设计出来的系统寿命都用不到拼多多改成拼夕夕的时候。
这种臆想出来的需求是自己给自己加戏。 |
113
MrYELiex 2020-05-15 21:39:14 +08:00
你们写代码不用枚举的?
|
114
tairan2006 2020-05-15 21:47:57 +08:00 via Android
数字+数据字典
|
115
souths 2020-05-15 22:41:08 +08:00
1 是给机器看的 淘宝是给人看的 建议搞下后端 一下子就明白了
|
116
icylogic 2020-05-15 22:53:31 +08:00 via iPhone 1
……anti corruption layer 了解一下,像什么淘宝改名,本来就是应该在这一层解决的事情,而且不同子系统之间对数据模型的关注点不一样很正常……
|
118
namelosw 2020-05-15 23:06:52 +08:00
@imlinhanchao 问题是用个列表就解决了……
|
119
yanqiyu 2020-05-15 23:19:14 +08:00 via Android
要我来设计可能会设计成 1,2,4,8,16
还能表达淘宝+拼多多--->1|2 算是被 C/C++给荼毒了吧,见不得额外开销 |
120
90xchun 2020-05-15 23:27:03 +08:00 via iPhone 2
你这都喜欢就是要干翻一船人的节奏呀,一大堆魔术值真的优雅吗?,enum 出了对外提供多套接口可能有客户端反序列化失败的情况,并没有其他大坑得,数据库查询效率的确存在,如果存在这样问题再想办法也来的急吧,况且代码是给人看的,数据库的字典表难道就不需要维护吗?我是不是随便基于某个类型的数据统计下,还要翻下码表。程序何苦难为程序员吗
|
121
mxalbert1996 2020-05-15 23:46:55 +08:00 via Android
楼主是觉得整数比较和字符串比较是一样的?
|
122
ArtIsPatrick 2020-05-16 01:25:57 +08:00 via iPhone
问这种问题的都不是专业程序员
|
123
baobao1270 2020-05-16 01:49:32 +08:00 via Android
动态类型搞字符串方便,如果后端是静态类型语言,enum 不香吗?
如果要前端显示出来的话,后端应当把要显示的值或映射传给前端 |
124
CoderGeek 2020-05-16 02:08:13 +08:00
后端可能是 enum 一个字典集
code msg 0 xxx 1 xxx 只是没给你全部返回给你定义了要传 code 而已 如果换成把字典都返回给你 是否就没意见了 |
125
romisanic 2020-05-16 02:19:21 +08:00
似乎希望语义化的都是前端,希望使用数字枚举的多数是后端
其实无非一个把枚举到语义转换的操作放在哪儿的问题,设计上肯定要分开,我可不想将来某个枚举改个名字要去改一堆的代码 前端想要后端做好,我直接展示;后端觉得枚举有了,返给你 key 值你映射一下有什么难的嘛 其实,对于一个量级比较大的服务,夸张点以谷歌为例,每天处理的空格的体积都非常大,如果返回去一堆汉字,那占用带宽更是大的多,前端 cache 一份枚举的缓存,针对枚举的字段客户端使用本地 cache 直接转换不挺好么 另外,如果这个枚举在客户端有需要处理的业务逻辑,到处 switch 或者 if 淘宝、京东,不觉得很 low 么?反正如果后端用这样的枚举如果看到绝壁要骂人的 这样涉及到不同环境,多个语言等情况,比较原始的类型比较安全,基本能始终保证统一,英文字符串也比汉字要强一些 最后,我是后端 🐶 |
126
binux 2020-05-16 02:31:38 +08:00 5
退一步,我可以接受用 ["pinduoduo", "taobao","jd"],但是不接受用中文。
因为一旦用了中文,就没有什么阻止前端直接拿它用来展示了。 而一个会拿枚举类型直接展示的前端,将来一定会在拼多多改名的时候来要求后端也改名的。 |
128
respect11 2020-05-16 09:28:10 +08:00 1
这种问题都能拉两页
|
130
ipwx 2020-05-16 10:35:06 +08:00 1
|
131
ipwx 2020-05-16 10:35:26 +08:00
前端无论如何都应该自己翻译后端过来的名字。。。
|
132
tedzhou1221 2020-05-16 10:39:25 +08:00 via iPhone
@namelosw 我就是那个用 0 、1 、2 、4 模仿 linux 权限的人😏
我们用一个状态码表示一个用户拥有多种权限 |
133
GrayXu 2020-05-16 17:37:29 +08:00
带宽占用啊,这一项就相差非常多了。这都不做优化?
|
135
imlinhanchao 2020-05-17 09:16:59 +08:00
@namelosw 因为在数据库存一个数字比存列表简单。
|
136
namelosw 2020-05-17 09:58:28 +08:00
@imlinhanchao 感觉这个算偷懒,多加个表关联就行了……
|
137
imlinhanchao 2020-05-18 08:57:24 +08:00
@namelosw 加表性能上就差了。不過確實這種方法其實在嵌入式上應用比較多。
|
138
cydleadingx 2020-06-08 11:40:48 +08:00
做为一个后端,你要是能数据库是 int,对外接口是 string,只能说你很不一般
|