关于前后端分离接口和展示层的一些问题

https://www.v2ex.com/t/579241?p=1

 

 

 

 

 

 

 

0 条未读提醒

V2EX  ›  程序员

关于前后端分离接口和展示层的一些问题

•  
•   1  
•  

   lihongjie0209 · 1 天前 · 4637 次点击  

1. 排序问题

假如接口返回的数据是 3 1 2, 但是前端需要展示的是 1 2 3, 并且没有分页, 一共就 3 条数据, 那么这个排序是前端做还是后端做.

1. 数据整理问题

假如接口返回的是一个数组, 但是前端需要一个树, 那么这个数据整理是前端做还是后端做.

我的想法是后端和展示层不依赖, 数据整理和排序都应该是展示层的工作.

实际情况是前端做起来很费力, 只能我专门写一个整理好的接口.

再次说明了: 技术问题最终还是人的问题.

第 1 条附言  ·  23 小时 17 分钟前

后端这些都可以做, 没问题. 但是因为树型接口我已经改了好几次了

刚开始我给了一个数组, 前端说组件不支持这种数据结构, 要我给一个树

我改接口, 给了一个树

测试提 BUG, 说树节点的顺序不对

前端说是我的接口问题

我又改接口, 增加了排序


上述的问题本来都可以避免的, 前端已经拿到了全量的数据, 怎么整理, 怎么排序都由前端决定.
现在, 测试给前端提 BUG, 前端再把 BUG 转给我, 大费周章值得吗

4637 次点击  ∙  23 人收藏   ∙  1 人感谢  

取消收藏  Tweet  Weibo  忽略主题  

感谢

•  
•  排序
•  
•  整理
•  
•  接口
•  
•  前端

125 回复  |  直到 2019-07-03 12:41:50 +08:00

1  2

❮ ❯

1MotherShip   1 天前 1 取决于这个接口是否有其他端调用，没有的话可以后端改 2 数据结构还是后端做吧

2akari33   1 天前 1.前端 2.后端做一个 vo 实体类返回给前端

3dongisking   1 天前 排序问题 一般是我后端做 数据整理问题 一般是我后端做（例：评论和 reply 评论）

4April5   1 天前 没说清楚前端难在哪

5LongMaoz   1 天前   ♥ 1 目前我是用 TypeScript 写前端数据结构，NetCore 写后端接口 后端的数据返回结构可能跟前端所需要的不一样，所以我前端是把后端的 BaseModel 搬过去作为基类， 然后前端的数据结构在 BaseModel 上 Extend，后端只做数据返回，比如你的第二种情况， 我是把后端的数据丢进前端的已经 Extend 的类种的构造函数里面进行实例化，这样就可以后端只返回数据 前端的 BaseModel 用来接收数据，同时创建新 Class 用来 Extend 基类，类中再进行数据转换以及整理，这样应该是可以完美实现你的需求的

6passerbytiny   1 天前 前端 Model 层或类似层，后端视图层或者端口适配层，都可以做，谁做只取决于谁愿意和有时间干，跟技术无关。技术上可以确认的是，非常不能让后端业务层去做，不建议前端展示层去做。

7stx2012   1 天前 via Android 当数据量大的时候，前端计算很费资源和时间，还是后端做比较好

8LongMaoz   1 天前 后端返回结构? export interface ApiResult<T> { code: number; msg: string; result: T; } T 里面放后端的数据结构基类 然后 T 类的 Extend 的类中定义构造器参数为 T 类 进行实例化就可以了 前端基于后端的 T 类 进行 extends 的结构（ Contact 类就是我 Group 类用到的基类，也就是后台返回的 T 类型）? export class Group extends Contact { public upperlimit: number; public creater: string; public announcement: string; constructor(baseGroup: BaseGroup) { super({ key: baseGroup.id.toString(), name: baseGroup.name, imgSrc: baseGroup.logo }); this.creater = baseGroup.createUserID.toString(); this.upperlimit = baseGroup.grade; this.announcement = baseGroup.description; } }

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  前端的重点是用后端的数据与用户交互 数据后端给, 交互的前端的事情. 至于前端拿到数据要怎么处理那是业务决定的, 后端不可能也不应该专门为了 UI 的方便而改接口

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 分钟前 推荐是前端转吧.我看像是后台管理的应用 能减少后端的业务混乱才是好前端 一对多.多对多.树形结构.后台管理本来数据量不大.没必要后端去拼接.. 前端都 vue react 有状态机了.很方便拼接的了. 我一般是让前端改..不会写的.我会帮前端写.然后再喷他们菜.一个数据处理都不会的前端都是 lj 所以前后端分离.不是一条心的..最终整个团队都是毒瘤了..接口数据拼接多.接口会忙.再加需求.后端抗不了的了 如果是 app 的那些接口.就统一后端处理数据了...最好前端只做展示.包括日期

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 你举的例子是两类问题。 要列表还是要树，后端做。 时间的格式，前端做（后端提供时间戳满足所有场景）。 对于第一类问题我说了，你接口是根据 UI 定的，从列表换到树，想必 UI 变了吧？而且改动还不小，有什么理由不重写接口呢？ 举个例子，通常接口返回的数据会有一层数据校验，在后端某个中间件上，你不打算改接口，返回的旧数据，而数据转换放在了前端，那一层服务就形同虚设了。

50raynor2011   22 小时 51 分钟前   ♥ 1 和显示强相关的，必须前端做啊

51lihongjie0209   22 小时 51 分钟前 @will0404 ui 变了, 但是数据还是那些数据

52527944441   22 小时 50 分钟前 第一个谁做都行 第二个我觉得做之前应该商议一下

53Caballarii   22 小时 49 分钟前 市场上彩笔前端太多了，培训班出来一点基本功都没有的，造成了都得后端帮忙的现状

54Sapp   22 小时 46 分钟前 第一个问题无所谓，第二个问题得看具体情况，如果就是这一份数据需要稍微转换一下，实际谁做都可以。但是如果这个结构涉及到很多接口的调用组合然后才能拼出来，那这个接口设计就有问题，也不存在谁做的问题了。

55TimPeake   22 小时 45 分钟前 作为前端做过类似的。 特别树形之类的复杂嵌套之类的数据，真的是后端做方便点。 后端可能几行代码解决了。 前端却需要十几行甚至几十行代码去转换格式化成理想数据，可能还有 BUG 总结：你把东西推给前端，工作流程没有错。但是出于道义，我建议你多为你的前端考虑一下

56lihongjie0209   22 小时 45 分钟前 @Sapp 全量数据, 不存在调用多个接口的问题

57deleteDB   22 小时 44 分钟前 第一个问题 后端做 如果有一天需要分页全表排序 前端是做不了的 还不如现在后端就做了 第二个问题 谁做都可以 数据量大推荐后端做 感觉没什么代码规范 要不然至少不应该有第一个问题 我是前端

58lizz666   22 小时 44 分钟前 让我想起了上个项目，涉及到腾讯广点通区域定向和今日头条区域定向数据，这两个平台返回的数据结构并不一致，我前端有个树形结构，需要按我树形结构格式给我数据。 头条的数据由于是死的，官方文档上有，我直接在前台写死处理好了。腾讯就比较 fuck 了，必须通过腾讯的接口才能拿到那么多数据，一开始，嫌烦，让后端帮我做，结果，数据太多，接口超时，后来实在没辙，还是交给我前台来处理了。

59keikeizhang   22 小时 44 分钟前 和 demo 操作没有关系的数据处理一律是后端的工作

60lihongjie0209   22 小时 42 分钟前 @TimPeake  同样的逻辑用 java 写和用 js 写代码量不会有太大的差距 后端实现的唯一好处在于标准库比较丰富, 静态检查比较严格.

61lihongjie0209   22 小时 41 分钟前 @deleteDB 第一个数据量是死的, 就几条

62tailf   22 小时 40 分钟前 这些前端数据格式化的需求，理论上需要配一个 API 层来处理，这一层只负责给前端需要的数据做聚合和结构处理，这个是有后端工程师做的，但是却属于大前端的范畴。 其实大多数常见的场景都很好办，上 GraphQL 规范，搞定。

63freakxx   22 小时 35 分钟前 这个问题其实主要看谁有空，谁方便，但有个平衡性 如果是数据展示的问题可以考虑类似 ?format=json or ?format=xml 这种方式 如果数据是固定的，资源性的，那么考虑 /api/<api>/xxx/这种给他做个特殊化，比如 /api/students-tree/ or /api/students/tree/

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 分钟前 本人是后端，工作久了就知道沟通的成本很贵，只要是我力所能及能做的我就做。 有时候排序是 sql 里加个 order 的事儿，后端不弄还要让前端去专门排序考虑数据正确性吗？ 有来回沟通的功夫早就弄好了，而且，这些活儿确实是该后端处理。

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 分钟前 这个得看情况 如果你的后端很重，有很多任务要做，比方说后端是一个负载均衡的网关，或者需要对个多展示层，那展示层的数据需要给前端做，或者再加一层数据处理层来专门做这个事情，比如说 GraphQL 如果你的后端仅仅只是简单的增删查改，我觉得还是尽量配合前端比较好

92CoCoMcRee   19 小时 4 分钟前 我这里 后端大多接口都会提供排序字段, 支持正反排序.  最外层肯定是树形结构. { "success": true, "errorCode": "", "message": "", "data": }

93CoCoMcRee   19 小时 2 分钟前 data 里头才是前端要的数据 而且 ,谁说只有后端才做数据校验 我这里前端对后端返的数据也要做数据校验的哦, 不同接口,校验的字段和结构都不一样哦.

94bdnet   18 小时 50 分钟前 1. 问题不应该是 没有事先约定好接口数据结构？ 2. 业务逻辑尽量收拢在一个地方，也就是后端，后端可以加一成，处理数据转换

95yufeng0681   15 小时 29 分钟前 1、还缺个组长，定义接口数据按什么排序返回； 2、后端做得越厚，前端就越简单，多个终端做起来一致性也容易保证。 3、你想做得灵活一点，就让前端传排序参数，支持多种排序方法返回数据。

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

❮ ❯

↑ 回到顶部

添加一条新回复

请尽量让自己的回复能够对别人有帮助

← V2EX

 

报告这个主题  

关于   ·   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