https://www.v2ex.com/t/579241?p=1
关于前后端分离接口和展示层的一些问题
- 1
lihongjie0209 · 1 天前 · 4637 次点击
- 排序问题
假如接口返回的数据是 3 1 2, 但是前端需要展示的是 1 2 3, 并且没有分页, 一共就 3 条数据, 那么这个排序是前端做还是后端做.
- 数据整理问题
假如接口返回的是一个数组, 但是前端需要一个树, 那么这个数据整理是前端做还是后端做.
我的想法是后端和展示层不依赖, 数据整理和排序都应该是展示层的工作.
实际情况是前端做起来很费力, 只能我专门写一个整理好的接口.
再次说明了: 技术问题最终还是人的问题.
第 1 条附言 · 23 小时 17 分钟前
后端这些都可以做, 没问题. 但是因为树型接口我已经改了好几次了
刚开始我给了一个数组, 前端说组件不支持这种数据结构, 要我给一个树
我改接口, 给了一个树
测试提 BUG, 说树节点的顺序不对
前端说是我的接口问题
我又改接口, 增加了排序
上述的问题本来都可以避免的, 前端已经拿到了全量的数据, 怎么整理, 怎么排序都由前端决定.
现在, 测试给前端提 BUG, 前端再把 BUG 转给我, 大费周章值得吗
4637 次点击 ∙ 23 人收藏 ∙ 1 人感谢
125 回复 | 直到 2019-07-03 12:41:50 +08:00
1 2 |
|
1MotherShip 1 天前 1 取决于这个接口是否有其他端调用,没有的话可以后端改 |
2akari33 1 天前 1.前端 2.后端做一个 vo 实体类返回给前端 |
3dongisking 1 天前 排序问题 |
4April5 1 天前 没说清楚前端难在哪 |
5LongMaoz 1 天前 ♥ 1 目前我是用 TypeScript 写前端数据结构,NetCore 写后端接口 |
6passerbytiny 1 天前 前端 Model 层或类似层,后端视图层或者端口适配层,都可以做,谁做只取决于谁愿意和有时间干,跟技术无关。技术上可以确认的是,非常不能让后端业务层去做,不建议前端展示层去做。 |
7stx2012 1 天前 via Android 当数据量大的时候,前端计算很费资源和时间,还是后端做比较好 |
8LongMaoz 1 天前 后端返回结构? |
9cwjokaka 1 天前 ♥ 3 如果我是前端,我会倾向于给后端做。反之亦然 |
10ben1024 1 天前 加个 Formatters 层 |
11lneoi 1 天前 如果整理数据太耗费时间,比如又排序又对比还得重新组织结构,或者多端都需要重复这一步骤,这块就归后端处理了。 |
12cyndihuifei 1 天前 ♥ 1 这种事情后端处理没什么好说的吧,我自己既是后端也是前端,很反感前端对接个接口还要处理来处理去 |
13liuhuansir 1 天前 你举例的两个,真的可以无所谓谁来做,完全看人的,有人觉得举手之劳,顺带就做了,有人嫌麻烦,就让对方做 |
14PerpetualHeng 1 天前 两种都有,前后端都可以,但是全部后端处理,会更好一些。 |
15bin20060407 1 天前 ♥ 2 前端能做,不代表前端一定要做,尽量让前端渲染数据更简单是我们这边后端团队的宗旨。 |
16kanezeng 1 天前 其实我觉得这两个例子都无所谓吧,大多数时候我都是后端直接做好了出来。不过如果真碰到需要转换的时候有时候我也放用户的前端,让用户的机器帮我们的后端分担点计算资源嘛。 |
17will0404 1 天前 via Android ♥ 7 这两点前端都能做,而且很简单,但不应该由前端来做。前端的职责是渲染和交互,仅此而已。 |
18serge001 23 小时 50 分钟前 我觉得前端做,这样才够灵活,不然你今天要这样的排序,明天又想要那样的排序,后端的接口岂不是要反复变;然后对于所说的扁平数据变树跟树状数据变扁平, 除非数据量很大,影响到了性能跟体验,还是在前端做比较好,因为前端可能同时用到扁平数据跟树状数据; |
19xuanbg 23 小时 45 分钟前 排序一般都是后端做,因为排序往往还有分页。树形显示不是只要对象包含 id 和父级 id,前端组件数据绑上去就好的吗? |
20lihongjie0209 23 小时 31 分钟前 @serge001 我主要也是有这方面的顾虑 |
21lihongjie0209 23 小时 30 分钟前 @xuanbg 不带分页的,审题 |
22lihongjie0209 23 小时 29 分钟前 @will0404 前端改 UI 的话, 需要的数据不变, 是不是后端就因为数据格式的问题还要改接口 |
23lihongjie0209 23 小时 27 分钟前 @liuhuansir 不是举手之劳的问题, 后面前端要改 UI, 你还要跟着改接口, 是耦合的问题 |
24zr8657 23 小时 26 分钟前 via Android 前端的重点是与用户的交互,这种处理数据结构的问题应该后端做。 |
25lihongjie0209 23 小时 23 分钟前 @zr8657 |
26Chingim 23 小时 23 分钟前 via Android ♥ 1 后端做。因为一个接口可能对接 web,安卓,ios 等等各种客户端,客户端做就重复劳动了。而且排序规则改变时,若干个端都需要改。 |
27lihongjie0209 23 小时 15 分钟前 @Chingim 没有多端, 所以暂时不考虑 |
28a62527776a 23 小时 10 分钟前 这种应该是需求定的把 怎么能因为前端说组件不支持就要求后端改接口呢 |
29will0404 23 小时 9 分钟前 via Android @lihongjie0209 你的假设就是错的,接口不应该根据 UI 来定。既然你接口要根据 UI 来定,那么 UI 变了接口跟着变不是合理的吗?这个点在于,接口不是跟着前端变,而是接口和前端都跟着 UI 变了。 |
30a62527776a 23 小时 6 分钟前 我感觉的问题是 |
31lihongjie0209 23 小时 6 分钟前 @will0404 我的意思是, UI 需要展示的数据我都发给前端, 至于说前端要展示 列表还是树状结构那是前端决定的. 就像前端展示 "2019 年 1 月 1 日" 或者是 "2019-01-01" 和我后端没关系 |
32OSF2E 23 小时 5 分钟前 ♥ 1 理论上说,交给前端来排序没有问题,但前提条件是 —— 由前端来决定什么时间请求数据以及如何请求数据。 |
33lihongjie0209 23 小时 5 分钟前 @a62527776a 嗯, 前端组件需要什么数据结构肯定是前端自己处理, 现在和后端接口耦合了 |
34lihongjie0209 23 小时 4 分钟前 @OSF2E 我说的费力是前端的组件需要一个树, 但是我给的是一个数组 |
35liuhuansir 23 小时 3 分钟前 @lihongjie0209 前端 UI 变,接口跟着变也是常事,再说就这两个例子又不复杂,后台跟着变也无关紧要吧,商量着来就行了 |
36Caballarii 23 小时 2 分钟前 所以现在经常有一层 API 转发,通常是 node,拿着后端大而全的数据,变成更精细的数据接口给前端用,属于前端的活 |
37version 23 小时 1 分钟前 推荐是前端转吧.我看像是后台管理的应用 |
38zmyongfeng 23 小时 1 分钟前 打得过就让他做。打不过就自己做 |
39lihongjie0209 23 小时 1 分钟前 @liuhuansir UI 变的意思是在所需数据不变的情况下调整 UI, 最简单的例子 前端展示 "2019 年 1 月 1 日" 改为 "2019-01-01", 这种情况下接口是不需要改变的 |
40KingOfUSA 23 小时 0 分钟前 前端做。 |
41unco020511 22 小时 59 分钟前 一般是后端处理,前端避免数据计算和整理 |
42lihongjie0209 22 小时 59 分钟前 @version 这种数据处理工作 map reduce filter 直接解决, 没什么复杂性, 下次我直接帮前端写代码 |
43liuhuansir 22 小时 59 分钟前 @lihongjie0209 我能说前端展示 "2019 年 1 月 1 日" 改为 "2019-01-01",这种需求,我们的后端都愿意帮忙实现。。。可能是我们工作量都不饱和吧,人家愿意做,我总不能拦着吧 |
44lihongjie0209 22 小时 58 分钟前 @liuhuansir ...........无话可说, 佩服佩服 |
45guorui112 22 小时 57 分钟前 ♥ 1 看和后端关系好不好,以前和一个关系比较好的后端做项目,都是抢着做,看哪边处理方便 |
46OSF2E 22 小时 56 分钟前 @lihongjie0209 锅背不动了,那就不背了 |
47version 22 小时 54 分钟前 @lihongjie0209 如果是后台管理最好要喷喷前端的了.不行就自己改了..后端再转..以后合并其它数据更加难..例如 table 是 5 个连表出来的数据...一个单独的 tag.都需要我转字段给他们..我就要说了..这无疑会搞垮整个 sql..后端再转多一层分明就是业务乱了.以前试过..后台管理不能让前端做话事权..能前端转数据的是最有利于以后迭代的.. |
4815651980765 22 小时 54 分钟前 我司前端没人权,此类工作都是前端在做,后台大部分时间都是直接给全量数据,前端要啥数据,自己遍历去取然后拼成想要的格式,我已经不止一次吐槽过后台了,然并卵! |
49will0404 22 小时 53 分钟前 via Android @lihongjie0209 你举的例子是两类问题。 |
50raynor2011 22 小时 51 分钟前 ♥ 1 和显示强相关的,必须前端做啊 |
51lihongjie0209 22 小时 51 分钟前 @will0404 ui 变了, 但是数据还是那些数据 |
52527944441 22 小时 50 分钟前 第一个谁做都行 第二个我觉得做之前应该商议一下 |
53Caballarii 22 小时 49 分钟前 市场上彩笔前端太多了,培训班出来一点基本功都没有的,造成了都得后端帮忙的现状 |
54Sapp 22 小时 46 分钟前 第一个问题无所谓,第二个问题得看具体情况,如果就是这一份数据需要稍微转换一下,实际谁做都可以。但是如果这个结构涉及到很多接口的调用组合然后才能拼出来,那这个接口设计就有问题,也不存在谁做的问题了。 |
55TimPeake 22 小时 45 分钟前 作为前端做过类似的。 |
56lihongjie0209 22 小时 45 分钟前 @Sapp 全量数据, 不存在调用多个接口的问题 |
57deleteDB 22 小时 44 分钟前 第一个问题 后端做 如果有一天需要分页全表排序 前端是做不了的 还不如现在后端就做了 |
58lizz666 22 小时 44 分钟前 让我想起了上个项目,涉及到腾讯广点通区域定向和今日头条区域定向数据,这两个平台返回的数据结构并不一致,我前端有个树形结构,需要按我树形结构格式给我数据。 |
59keikeizhang 22 小时 44 分钟前 和 demo 操作没有关系的数据处理一律是后端的工作 |
60lihongjie0209 22 小时 42 分钟前 @TimPeake |
61lihongjie0209 22 小时 41 分钟前 @deleteDB 第一个数据量是死的, 就几条 |
62tailf 22 小时 40 分钟前 这些前端数据格式化的需求,理论上需要配一个 API 层来处理,这一层只负责给前端需要的数据做聚合和结构处理,这个是有后端工程师做的,但是却属于大前端的范畴。 |
63freakxx 22 小时 35 分钟前 这个问题其实主要看谁有空,谁方便,但有个平衡性 |
6415651980765 22 小时 32 分钟前 @lihongjie0209 话说请教一下数据量大的时候,放在前端处理,对页面性能会不会有什么影响? |
65serge001 22 小时 27 分钟前 我是前端,反正我觉得这些大部分情况下都应该在前端处理,为了处理数据格式没必要加多个 node 中间层... |
66limuyan44 22 小时 25 分钟前 via Android 解决问题最快的方法是让测试直接把 bug 提给你,这样不就不大费周章了。 |
67KingOfUSA 22 小时 7 分钟前 因为有类似的问题,所以现在团队里面的前后端交互都是让后端的同事来负责(美名其曰 全栈),前端的同事负责做静态页面以及后端解决不了的问题。 |
68hedamao9999 22 小时 7 分钟前 via Android 我前后端都做,做前端的时候我就跟后端说数据随便给,我自己处理成合适的格式,只要别多余浪费就行,比如要五条给十条,要十个字段给二十个字段之类的;做后端提供接口的时候就找前端确认好要的结构,争取他们不怎么用写任何多余的处理逻辑就渲染出界面,。这件事怎么做感觉就是存乎一心,做有做的道理,不做也有不做的道理,如果有合适的机会,前后端都做一下,你会对这件事有不一样的感悟的 |
69Yuicon 22 小时 2 分钟前 看了半天 就是一个扯皮的问题 |
70l00t 22 小时 0 分钟前 当然应该前端做。这就是个前端显示的需求,跟后端有什么关系。 |
71coolooks 21 小时 54 分钟前 有时间来这里扯皮,没时间改接口,闲的蛋疼 |
72lihongjie0209 21 小时 52 分钟前 @coolooks 接口早就写好了, 只是讨论一下这个问题而已 |
73lihongjie0209 21 小时 51 分钟前 @Yuicon 是一个规范的问题 |
74rr41ns 21 小时 48 分钟前 都是后端处理。 |
75rr41ns 21 小时 44 分钟前 本人是后端,工作久了就知道沟通的成本很贵,只要是我力所能及能做的我就做。 |
76drlalll 21 小时 39 分钟前 事实上很多前端只会做界面,逻辑非常差。所以一般逻辑问题都是后端处理好,当然你们这个问题属于沟通不畅。 |
77coang 21 小时 38 分钟前 如果是树后端做比较好.. 你排序问题 要加数据处理 而不是说前端要这个顺序接口就改成这个顺序.. 排序问题要对应有排序的参数... ps.我是后端 |
78zydxn 21 小时 36 分钟前 第一种情况,一般接口都有默认排序,如果业务需求上来回变化,走配置。 |
79passerbytiny 21 小时 31 分钟前 @lihongjie0209 这个其实后端做也是可以的,后端可以在不动领域模型 /服务核心层的情况下,针对不同的前端、版本、特殊定制出不同的接口。传统的 Dao-Service-Controller 分层,如果正确的隔离 Service 层和 Controller 层,是很容易以很少的工作量来实现这种效果的。此时,接口由前端定义——但前端需要深入了解领域模型或业务模型。这样安排,对整体的好处是前后端之间更加松散。对后端的好处是:后端虽然没有了接口的主要控制权,但也没有了定义接口的责任。 |
80hyy1995 21 小时 31 分钟前 其实这些个逻辑前后端都能写。但接口可能会多页面重复调用,如果是这样的话数据格式还是后端处理比较好 |
81tingfang 21 小时 31 分钟前 都可以,我觉得后端做更好一些,前端如果是 APP 或者小程序,逻辑改动还需要审核发布,后端做的话改起来会更方便些? |
82a122996325 21 小时 29 分钟前 数据量不大 随便都可以吧 数据量稍微大点 还是后台做吧 |
83dicc 21 小时 27 分钟前 用户量大的话,后端做就不好了 |
84Hakka 21 小时 26 分钟前 排序问题 |
85dongxiao 21 小时 23 分钟前 看是否改动频繁吧,如果改动频繁前端做比较好点,不然每次调整页面都需要改动接口,如果基本定下来不会动了,后端改起来还是要快点,话说公司最近的一个项目包括页面显示的文字都是我这接口返回的,就是 No.1 xxxx No.2 xxxx 这种,前后端还是要多多配合,都是为了进度不是嘛 |
86zsy979 21 小时 2 分钟前 到底由谁做?没人能给最终结论 |
87x7395759 19 小时 57 分钟前 此时就需要多一个层了 |
88mmuggle 19 小时 46 分钟前 GraphQL |
89ljtletters 19 小时 46 分钟前 树的话我一般每个节点会额外给一个排序字段,层级字段。 |
90xianxiaobo 19 小时 39 分钟前 建议分成三个职位,一个后端,只做数据库的增删查改,一个前端,只做页面渲染,交互和样式书写,还有一个中端,专门做数据转换,将前端传入的数据转换为后端想要的数据,将后端返回的数据转换为前端想要的数据,以此解决此类扯皮问题。 |
91MoRun 19 小时 16 分钟前 这个得看情况 |
92CoCoMcRee 19 小时 4 分钟前 我这里 后端大多接口都会提供排序字段, 支持正反排序. |
93CoCoMcRee 19 小时 2 分钟前 data 里头才是前端要的数据 |
94bdnet 18 小时 50 分钟前 1. 问题不应该是 没有事先约定好接口数据结构? |
95yufeng0681 15 小时 29 分钟前 1、还缺个组长,定义接口数据按什么排序返回; |
96petelin 15 小时 18 分钟前 via iPhone 屁大点事 这都无所谓 当时文档怎么写的就怎么改 |
97nidaye999 15 小时 9 分钟前 后端做,这么弱智的问题 |
98a852695 10 小时 55 分钟前 尽量后端做,前端核心是交互和数据可视化,你非觉得 chrome 性能好到比你服务器还快,那你就前端做吧 |
99a86356 6 小时 31 分钟前 via iPhone 后端做,数据结构后端做,给前端需要的数据结构即可。前端也一样的,提交数据的时候给你需要的数据结构。没什么好说。前端主要是交互。而且排序什么的,后端处理一 order 的问题,前端做还要遍历再排序,浪费时间。前端要做的是一些小的数据转换显示,比如时间搓,一些状态,1.2.3 转成对应文字。 |
100a86356 5 小时 0 分钟前 via iPhone @hedamao9999 说的很对,都做过考虑会比较周全。要不然一叶障目 |
1 2 |
|
添加一条新回复
请尽量让自己的回复能够对别人有帮助
关于 · FAQ · API · 我们的愿景 · 广告投放 · 感谢 · 实用小工具 · 3275 人在线 最高记录 5043 · Select Language创意工作者们的社区World is powered by solitudeVERSION: 3.9.8.3 · 35ms · UTC 04:53 · PVG 12:53 · LAX 21:53 · JFK 00:53
♥ Do have faith in what you're doing.
沪ICP备16043287号-1 |