比如说是一个问题的对象 list，对象下面一个 options 的 list，这个 list 长度可能会有三个，也可能会有两个。但是实际选择的时候只要长度为 2 的问题对象，就需要把 list 里面有 3 个的问题对象过滤掉。这种一般是前端做过滤还是后端。
我们公司凡是数据处理过滤都是前端处理，后端只提供接口的，不知道大家的公司是怎么处理的。 类似这种数据结构
[ { // 问题对象 options: [''好,'不好','很好] // 就是这个 list==3 个 qeId: 4419 quizContent: "你好吗" quizId: 4406 status: 0 }, { options: [''好,'不好'] // 就是这个 list==2 个 qeId: 4419 quizContent: "你好吗" quizId: 4406 status: 0 } ]
 |
1
wu67 Nov 12, 2018
简单的处理一下也没什么呀, 太过复杂的就不爽了
|
 |
2
chenlaocong OP @wu67 这个对象 list 的外面还有几层的对象
|
 |
3
hongch Nov 12, 2018
后端
|
 |
4
ibegyourpardon Nov 12, 2018
看情况，这时候你们很可能需要。。。中间层。
大的后端，只负责数据收发存储，也就是你们现在意义的后端。 对数据的这种过滤和处理，你们现在是前端做，我们也是，但我们也发现有的时候这样很麻烦，能直接给到前端处理过的就好了。 可是又不能直接塞给后端，这种和业务很亲近的数据处理给后端都来做，很容易过度入侵后端，冲击他们已经梳理的不错的接口和规范。 我们虽然不像阿里之类的大公司有所谓 Node 编写的一个中间层，但也在尝试，其实就是根据具体业务需求把后端给过来的数据再包装一次给前端，让前端好处理点。这个部分很多公司都是前端自己来做了，因为所谓前端是离业务最近的人嘛，但我觉得用 PHP 等后端语言处理包装下接口也没什么不可以的。 反正一般谁来做这种数据处理，我们倾向于看谁做的快……谁做的快谁来搞下，毕竟不存在绝对意义上的一个人加班，一个人加班十有八九是要另外一端的人协助配合的。 |
 |
5
yidinghe PRO 前段根据自己的需要处理数据，不能因为前端的问题影响后端。
|
 |
6
qqqtz Nov 12, 2018
大部分后端都是做通用服务的，不能完完全全对应你页面逻辑需要的数据，要不像大厂做 node 中间层做数据整合，现在其实很普遍了，不做中间层就自己在 web 端做一个数据层管理。
|
 |
7
lopedever Nov 12, 2018
同有这个问题，觉得还是得根据情况考虑吧。
今天要用长度为 2 的数组，万一过几天又要用长度为 3 的了呢，如果都要后端来搞的话感觉不太对。 看评论中间层不错，有精力可以搞下，也不一定用 node 吧，写个类似的模块也可以。 |
|
8
lopedever Nov 12, 2018
另外搭车问下接口返回的数组，很多情况如果没有内容后端会返回 null，前端还要写额外的 data && data.forEach 这种代码，这种情况后端返回一个空数组 [] 是不是比较好？
还是有什么更好的解决办法？ |
 |
9
yangehappy Nov 13, 2018
@lopedever 这种情况当然是和后端约定好没有内容直接给[] 你本来想要的数据结构就是数组 即使没有内容 也要给空数组呀
|
 |
10
method Nov 13, 2018
光看你这个例子，可能前后端处理都无所谓。没有给出规模和完整场景，很难给出答案。感觉有以下几个因素要考虑：
1. 响应报文里的某个数据在前端是否有多个地方使用，不同地方是不是有不同的过滤需求。如果是多个地方都要用，总不能让后端一个模块给你准备一份数据吧？应该是一份数据源，前端自己做数据分发。 2. 如果只有一个模块用，并且数组很长，那考虑到传输性能，特别是移动端条件下，让后端过滤好了再给前端，是合理的。这样做还有一个好处是，调整过滤条件也比较容易，直接后端发布就好了。 3. 从开发资源配比上来看，如果是一个接口同时给 PC 和移动端使用，甚至于移动端又细分为 iOS 和安卓，那放在后端是划算的。 |
Select Language