直接从数据库中取得模型,不需要的值就是一堆 null
如果是需要额外处理的字段,就在原本对象内放一个 params 的对象,再嵌套一层放处理的数据
能因为一个值需要转换一下数据而扯皮,哪怕是取模于 10 这种简易操作也要前端来做
101
NjcyNzMzNDQ3 2022-04-14 14:17:47 +08:00
我前后端都写,不同意通用性、模 10 都不处理之类的观点。
前端代码也在服务器,发版还好说。ios/android 客户端也用后端接口,难不成每次都让客户端改?直接改后端不改客户端才是好接口! 后端本就是处理数据结构、算法的,啥都前端做,前端 nodejs/云生成 api 直接调用数据库算了。 |
102
ypzhou 2022-04-14 14:19:07 +08:00
垃圾呗,还有什么原因。自己想省事,累别人。
|
103
ikaros 2022-04-14 14:26:29 +08:00
这个把 openid 都带出来多少有点过分,没得洗,作为后端我都觉得不能忍
|
104
Marszm 2022-04-14 14:36:41 +08:00
太懒了哈哈哈。。。曾经赶工期偷懒写过一两次,被前端大爷凶了半天,就不敢了。
|
105
ytmsdy 2022-04-14 14:41:29 +08:00
居然还有 oldPassword 字段!优秀!
|
108
fenglangjuxu 2022-04-14 15:24:36 +08:00
作为一个后端 表示很惊奇 还有这么 low 的做法
|
109
Lweiis 2022-04-14 15:32:29 +08:00
作为一个后端,我觉得,完全用不到的字段,是没必要传的。该字段只是有可能为 null ,则应该保留,但前公司的后端架构是将 null 字段在序列化阶段直接去除了,在高访问场景下应该有一丢丢性能优化
|
110
NakeSnail 2022-04-14 15:41:08 +08:00
看过的 java 项目或多或少都有这样的接口
|
111
jqtmviyu 2022-04-14 15:56:26 +08:00
我一般是让后端精简无效的字段, 传输速度快点, 字段少也方便控制台看.
取模 / 百分比转换 / 时间戳 之类的还好. 递归成级联 我也能接受 |
112
elevioux 2022-04-14 16:04:42 +08:00
php 后端,觉得单纯的就是懒。至少得 select <需要的字段> from table 啊,直接 * 的话有点不负责任了。
|
114
hejw19970413 2022-04-14 16:22:59 +08:00
额 这种就好比 p2p 下载器
|
115
YIsion 2022-04-14 16:29:31 +08:00
mybaits-plus 用久了就这样
|
116
EscYezi 2022-04-14 16:53:05 +08:00 via iPhone
@YIsion #115 mybatis-plus 只是个 orm 封装,跟接口返回值又没有关系。还是人的问题。
|
117
bootvue 2022-04-14 16:55:02 +08:00
懒
|
118
wolfie 2022-04-14 16:59:02 +08:00
@NjcyNzMzNDQ3 #101
典中典,只有跟自己相关的才是前端,其他客户端都不算前端。 |
120
encro 2022-04-14 17:27:19 +08:00
没什么问题。
大部分框架都会默认 select *的,否则难道数据库有 20 个字段,还一个一个写不成。 一般来说都是直接在模型里面定义那个字段需要在那个场景输出,没有定义就是默认输出。 看框架 这样做坏处是暴露字段,好处也是暴露字段(字段都显示了,前端不用靠文档,直接复制粘贴吧)。 安全隐患较少,像 django rest 这样的,默认还将每个参数注释都显示出来呢,都是为了方便。 |
121
m16FJ06l0m6I2amP 2022-04-14 17:28:55 +08:00
这些 null 再数据库是不是 None,数据库没给默认值吗
|
122
encro 2022-04-14 17:32:51 +08:00
@NjcyNzMzNDQ3
取模应该放在前端还是后端? 我的界限是: 1 ,业务展示要求,一般放前端,但是非常大可能性经常变得,放后端; 2 ,业务逻辑需求,一般放后端,除非前端运算能带来体验大幅提升且无发作用; 所以这是一门艺术。 |
123
fuchish112 2022-04-14 17:51:06 +08:00
一种是淡化后端逻辑,前端根据不同平台 h5/app ,个性化输出
一种是后端整理逻辑,前端纯展示 当然现实中两者的边界,可能是动态变化的。 |
124
lovelylain 2022-04-14 18:46:29 +08:00 via Android
看场景吧,如果你这就是个内部后台管理系统,直接维护 DB 的,这么操作不很正常么?或者是一个后台内部公共服务,面向的业务会用到哪些字段是不确定的,怎么去砍字段?如果是对接前端的业务接口,就应该按业务需要重新定义一下。
|
125
notwaste 2022-04-15 00:11:20 +08:00
取模于 10 这个个人觉得交给前端做好些
这个 null 返回挺纠结的,不处理确实不安全容易暴露表结构以及占用传输带宽,但是一个查询接口就需要写一个对应的 VO 的话会不会又导致项目过于冗余庞大 |
126
Anivial 2022-04-15 19:51:09 +08:00
结论:少一个架构师
1. 在做业务之前没有定义好 API 的输入与输出,如果事先定义好了,后端专心返回对应数据(即便是多了一些数据,到时候的性能问题排查也肯定是后端的问题),前端专心根据 mock 设计页面逻辑(没必要纠结多个字段,少个字段) 2. 开发流程,从你拿到后端接口数据才抱怨就很明显知道了,前端要等后端开发完接口才能规划数据,完全没有必要啊,就拿你的取模来说,result = response.data.datamod 和 result = response.data.datamod % 10 两个区别很大吗?何必一定要完完整整的你要什么给你什么呢?那如果有一天你要计算哈希值也先帮你算好? 简单来说,后端负责业务数据的存储,安全,稳定,一致,前端负责展示数据,解析数据,计算数据。 其实说到最后就是工作量的问题,如果需求变动,谁来改,就单单你说的取模,需求变成取模 100 ,要么后端改,要么前端改,你们要不掰个手腕? |
128
mokevip OP “哪怕是取模于 10 这种简易操作也要前端来做”
只是讲我们后端不灵活的一个例子 这个问题的出现是,后端的某个状态值 1 ,2 ,3 分别对应不同状态,并且告诉我,11 、12 、13 也是相同的状态,你取模一下 10 就行了 我不同意是因为 1. 前端并不需要知道 1 和 11 的区别,所以前端只需要知道 1 个值对应一个状态就行了 2. 因为该项目是多端项目,接口存在复用,如果这种取模于 10 存在多个项目中,会很难管理 |