V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member Sign In
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 1485 days ago, the information mentioned may be changed or developed.
直接从数据库中取得模型，不需要的值就是一堆 null
如果是需要额外处理的字段，就在原本对象内放一个 params 的对象，再嵌套一层放处理的数据
能因为一个值需要转换一下数据而扯皮，哪怕是取模于 10 这种简易操作也要前端来做
 |
101
NjcyNzMzNDQ3 Apr 14, 2022
我前后端都写，不同意通用性、模 10 都不处理之类的观点。
前端代码也在服务器，发版还好说。ios/android 客户端也用后端接口，难不成每次都让客户端改？直接改后端不改客户端才是好接口！ 后端本就是处理数据结构、算法的，啥都前端做，前端 nodejs/云生成 api 直接调用数据库算了。 |
 |
102
iiqiu Apr 14, 2022
垃圾呗,还有什么原因。自己想省事,累别人。
|
 |
103
ikaros Apr 14, 2022
这个把 openid 都带出来多少有点过分，没得洗，作为后端我都觉得不能忍
|
 |
104
Marszm Apr 14, 2022
太懒了哈哈哈。。。曾经赶工期偷懒写过一两次，被前端大爷凶了半天，就不敢了。
|
 |
105
ytmsdy Apr 14, 2022
居然还有 oldPassword 字段！优秀！
|
 |
108
keepfun Apr 14, 2022
作为一个后端 表示很惊奇 还有这么 low 的做法
|
 |
109
Lweiis Apr 14, 2022
作为一个后端，我觉得，完全用不到的字段，是没必要传的。该字段只是有可能为 null ，则应该保留，但前公司的后端架构是将 null 字段在序列化阶段直接去除了，在高访问场景下应该有一丢丢性能优化
|
 |
110
NakeSnail Apr 14, 2022
看过的 java 项目或多或少都有这样的接口
|
 |
111
jqtmviyu Apr 14, 2022
我一般是让后端精简无效的字段, 传输速度快点, 字段少也方便控制台看.
取模 / 百分比转换 / 时间戳 之类的还好. 递归成级联 我也能接受 |
 |
112
elevioux Apr 14, 2022
php 后端，觉得单纯的就是懒。至少得 select <需要的字段> from table 啊，直接 * 的话有点不负责任了。
|
 |
114
hejw19970413 Apr 14, 2022
额 这种就好比 p2p 下载器
|
 |
115
YIsion Apr 14, 2022
mybaits-plus 用久了就这样
|
 |
117
bootvue Apr 14, 2022
懒
|
 |
118
wolfie Apr 14, 2022
@NjcyNzMzNDQ3 #101
典中典，只有跟自己相关的才是前端，其他客户端都不算前端。 |
 |
120
encro Apr 14, 2022
没什么问题。
大部分框架都会默认 select *的，否则难道数据库有 20 个字段，还一个一个写不成。 一般来说都是直接在模型里面定义那个字段需要在那个场景输出，没有定义就是默认输出。 看框架 这样做坏处是暴露字段，好处也是暴露字段（字段都显示了，前端不用靠文档，直接复制粘贴吧）。 安全隐患较少，像 django rest 这样的，默认还将每个参数注释都显示出来呢，都是为了方便。 |
 |
121
m16FJ06l0m6I2amP Apr 14, 2022
这些 null 再数据库是不是 None,数据库没给默认值吗
|
|
122
encro Apr 14, 2022
@NjcyNzMzNDQ3
取模应该放在前端还是后端？ 我的界限是： 1 ，业务展示要求，一般放前端，但是非常大可能性经常变得，放后端； 2 ，业务逻辑需求，一般放后端，除非前端运算能带来体验大幅提升且无发作用； 所以这是一门艺术。 |
 |
123
fuchish112 Apr 14, 2022
一种是淡化后端逻辑，前端根据不同平台 h5/app ，个性化输出
一种是后端整理逻辑，前端纯展示 当然现实中两者的边界，可能是动态变化的。 |
 |
124
lovelylain Apr 14, 2022 via Android
看场景吧，如果你这就是个内部后台管理系统，直接维护 DB 的，这么操作不很正常么？或者是一个后台内部公共服务，面向的业务会用到哪些字段是不确定的，怎么去砍字段？如果是对接前端的业务接口，就应该按业务需要重新定义一下。
|
 |
125
notwaste Apr 15, 2022
取模于 10 这个个人觉得交给前端做好些
这个 null 返回挺纠结的，不处理确实不安全容易暴露表结构以及占用传输带宽，但是一个查询接口就需要写一个对应的 VO 的话会不会又导致项目过于冗余庞大 |
 |
126
Anivial Apr 15, 2022
结论：少一个架构师
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 存在多个项目中，会很难管理 |
Select Language