我们公司是前端不想做字段 key 到 value 的映射,要求每次返回给前端时都返回具体的枚举信息。有时候我们就得跨服务去查询枚举用户信息、字典信息。 甚至是原本可能是一个相对复杂的对象,前端都要求把对象重组,最好平铺着放到外层实体中。
{ 'object':{ 'key':'value' } }
我觉得这样不太合理,但是前端不愿意做,领导对此也不支持。V 友们你们觉得呢?我又该如何说服他们和领导呢?
![]() | 1 ychost 2024-09-13 17:46:09 +08:00 ![]() 所以需要一个 BFF 层,这玩意前后端做都不合适 |
2 fingerxie OP @ychost 我感觉 BFF 层一方面是人力成本的上升,公司不会支持。另一方面这 BFF 层不应该是前端映射久了,厌倦了,由此衍生出的吗? |
3 woodytang 2024-09-13 17:55:25 +08:00 没听明白,他要你在 DTO 层做很多连表 ,对象转换变形吗? 还是说你枚举信息的返回格式?? 枚举信息你给他一个统一接口,让他到你的字典里面查不就可以了 |
4 hetal 2024-09-13 18:19:18 +08:00 我们用的是 protobuf 来统一前后端( Web/App 等),一键生成自己想要的代码 |
![]() | 5 rabbbit 2024-09-13 18:24:21 +08:00 没看懂,举个实际的例子? |
![]() | 6 rabbbit 2024-09-13 18:27:28 +08:00 是这个意思嘛? 你的 { 'user': {name: '', age: '', sex: '1'}, } |
![]() | 7 rabbbit 2024-09-13 18:28:51 +08:00 前端要求的 { 'user': {name: '', age: '', sex: '男'}, } 然后有个字典表 {1: '男',2: '女'} 是这样吗? |
8 07aPzknB16ui9Cp3 2024-09-13 18:35:54 +08:00 个人实践是服务器处理,因为对多端的时候不可能让每一端自己都这样拼接一遍,所以接口对外会有一套 model ;然后问题是如何快速生成和分发这个 model 至客户端,比如以代码生成的方式生成给各个端,而不是让客户端手打一遍 |
9 flmn 2024-09-13 18:37:01 +08:00 我一般这样给前端返回的: { 'user': {name: '', age: '', sex: '1', sexName: '男'}, } 自取所需。 |
11 worldgg 2024-09-13 22:43:31 +08:00 我们公司也是,需要字典翻译的都是统一后端翻译好,不会交给前端,一般在需要翻译的字段名称加上 label 。比如 {sex:"1",sexlabel:"男"},很久之前也是让前端自己用字典表翻译,但是会有个问题,如果一个页面需要翻译的字段特别多,并且字典表又很大的情况下(比如客户,城市,地址),页面会很卡顿,用户体验非常差,所以后面都统一都是后端翻译好。 |
![]() | 12 guanzhangzhang 2024-09-14 00:36:40 +08:00 |
![]() | 13 lyxxxh2 2024-09-14 09:34:18 +08:00 看得我一脸懵逼,读了一遍又一遍才理解意思。 第一遍: 后端问题返回问题,还得继续看 第二遍: 前端不想做,领导对你也不支持。 第三遍: 前端不想做,领导也不支持前端。 第四遍: "我又该如何说服他们和领导呢?" 领导原来支持前端了。 ... 你所举的对象,返回很正常。 看了 6 楼才知道啥问题。 前端不会问我这些问题,我常量复制到接口文档,自己看。 |
14 reallycool 2024-09-14 10:18:06 +08:00 给他们说,能干就干,不干滚蛋 |
![]() | 15 oldManNewThought 2024-09-14 15:01:37 +08:00 我们这样做。后端返回的字典,该什么就是什么。前端有个专门的字典组件。属性设置成字典的类型。内部就请求后端获取对应的翻译。同时在前端会做缓存,不用每次请求 |
16 xxxbin 2024-10-04 04:26:48 +08:00 偷偷问一句重组的代码不是写一次就行?需要每次都写? |