V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
lihongjie0209
V2EX  ›  程序员

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

  •  1
     
  •   lihongjie0209 · 2019-07-02 11:41:09 +08:00 · 10705 次点击
    这是一个创建于 1731 天前的主题,其中的信息可能已经有所发展或是发生改变。
    1. 排序问题

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

    1. 数据整理问题

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

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

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

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

    第 1 条附言  ·  2019-07-02 13:36:28 +08:00
    后端这些都可以做, 没问题. 但是因为树型接口我已经改了好几次了

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

    我改接口, 给了一个树

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

    前端说是我的接口问题

    我又改接口, 增加了排序


    上述的问题本来都可以避免的, 前端已经拿到了全量的数据, 怎么整理, 怎么排序都由前端决定.
    现在, 测试给前端提 BUG, 前端再把 BUG 转给我, 大费周章值得吗
    131 条回复    2019-07-03 15:15:49 +08:00
    1  2  
    MotherShip
        1
    MotherShip  
       2019-07-02 11:44:16 +08:00
    1 取决于这个接口是否有其他端调用,没有的话可以后端改

    2 数据结构还是后端做吧
    akari33
        2
    akari33  
       2019-07-02 11:45:01 +08:00
    1.前端 2.后端做一个 vo 实体类返回给前端
    dongisking
        3
    dongisking  
       2019-07-02 11:47:02 +08:00
    排序问题
    一般是我后端做
    数据整理问题
    一般是我后端做(例:评论和 reply 评论)
    April5
        4
    April5  
       2019-07-02 11:47:05 +08:00
    没说清楚前端难在哪
    LongMaoz
        5
    LongMaoz  
       2019-07-02 11:53:13 +08:00   ❤️ 1
    目前我是用 TypeScript 写前端数据结构,NetCore 写后端接口
    后端的数据返回结构可能跟前端所需要的不一样,所以我前端是把后端的 BaseModel 搬过去作为基类,
    然后前端的数据结构在 BaseModel 上 Extend,后端只做数据返回,比如你的第二种情况,
    我是把后端的数据丢进前端的已经 Extend 的类种的构造函数里面进行实例化,这样就可以后端只返回数据
    前端的 BaseModel 用来接收数据,同时创建新 Class 用来 Extend 基类,类中再进行数据转换以及整理,这样应该是可以完美实现你的需求的
    passerbytiny
        6
    passerbytiny  
       2019-07-02 11:54:20 +08:00
    前端 Model 层或类似层,后端视图层或者端口适配层,都可以做,谁做只取决于谁愿意和有时间干,跟技术无关。技术上可以确认的是,非常不能让后端业务层去做,不建议前端展示层去做。
    stx2012
        7
    stx2012  
       2019-07-02 11:56:45 +08:00 via Android
    当数据量大的时候,前端计算很费资源和时间,还是后端做比较好
    LongMaoz
        8
    LongMaoz  
       2019-07-02 12:00:34 +08:00
    后端返回结构👇

    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;
    }
    }
    cwjokaka
        9
    cwjokaka  
       2019-07-02 12:10:22 +08:00   ❤️ 3
    如果我是前端,我会倾向于给后端做。反之亦然
    ben1024
        10
    ben1024  
       2019-07-02 12:13:48 +08:00
    加个 Formatters 层
    lneoi
        11
    lneoi  
       2019-07-02 12:14:23 +08:00
    如果整理数据太耗费时间,比如又排序又对比还得重新组织结构,或者多端都需要重复这一步骤,这块就归后端处理了。
    cyndihuifei
        12
    cyndihuifei  
       2019-07-02 12:17:48 +08:00   ❤️ 1
    这种事情后端处理没什么好说的吧,我自己既是后端也是前端,很反感前端对接个接口还要处理来处理去
    liuhuansir
        13
    liuhuansir  
       2019-07-02 12:21:22 +08:00
    你举例的两个,真的可以无所谓谁来做,完全看人的,有人觉得举手之劳,顺带就做了,有人嫌麻烦,就让对方做
    PerpetualHeng
        14
    PerpetualHeng  
       2019-07-02 12:22:55 +08:00
    两种都有,前后端都可以,但是全部后端处理,会更好一些。
    bin20060407
        15
    bin20060407  
       2019-07-02 12:25:48 +08:00   ❤️ 2
    前端能做,不代表前端一定要做,尽量让前端渲染数据更简单是我们这边后端团队的宗旨。
    kanezeng
        16
    kanezeng  
       2019-07-02 12:34:00 +08:00
    其实我觉得这两个例子都无所谓吧,大多数时候我都是后端直接做好了出来。不过如果真碰到需要转换的时候有时候我也放用户的前端,让用户的机器帮我们的后端分担点计算资源嘛。
    will0404
        17
    will0404  
       2019-07-02 12:42:28 +08:00 via Android   ❤️ 8
    这两点前端都能做,而且很简单,但不应该由前端来做。前端的职责是渲染和交互,仅此而已。
    通常不太负责的后端会说,这么简单的事你前端做一下就好了,我会怼回去,你不会写的话我来帮你写后端。
    serge001
        18
    serge001  
       2019-07-02 13:03:20 +08:00
    我觉得前端做,这样才够灵活,不然你今天要这样的排序,明天又想要那样的排序,后端的接口岂不是要反复变;然后对于所说的扁平数据变树跟树状数据变扁平, 除非数据量很大,影响到了性能跟体验,还是在前端做比较好,因为前端可能同时用到扁平数据跟树状数据;
    xuanbg
        19
    xuanbg  
       2019-07-02 13:08:05 +08:00
    排序一般都是后端做,因为排序往往还有分页。树形显示不是只要对象包含 id 和父级 id,前端组件数据绑上去就好的吗?
    lihongjie0209
        20
    lihongjie0209  
    OP
       2019-07-02 13:22:38 +08:00
    @serge001 我主要也是有这方面的顾虑
    lihongjie0209
        21
    lihongjie0209  
    OP
       2019-07-02 13:22:58 +08:00
    @xuanbg 不带分页的,审题
    lihongjie0209
        22
    lihongjie0209  
    OP
       2019-07-02 13:24:43 +08:00
    @will0404 前端改 UI 的话, 需要的数据不变, 是不是后端就因为数据格式的问题还要改接口
    lihongjie0209
        23
    lihongjie0209  
    OP
       2019-07-02 13:26:07 +08:00
    @liuhuansir 不是举手之劳的问题, 后面前端要改 UI, 你还要跟着改接口, 是耦合的问题
    zr8657
        24
    zr8657  
       2019-07-02 13:26:57 +08:00 via Android
    前端的重点是与用户的交互,这种处理数据结构的问题应该后端做。
    lihongjie0209
        25
    lihongjie0209  
    OP
       2019-07-02 13:30:26 +08:00
    @zr8657
    前端的重点是用后端的数据与用户交互
    数据后端给, 交互的前端的事情.
    至于前端拿到数据要怎么处理那是业务决定的, 后端不可能也不应该专门为了 UI 的方便而改接口
    Chingim
        26
    Chingim  
       2019-07-02 13:30:53 +08:00 via Android   ❤️ 1
    后端做。因为一个接口可能对接 web,安卓,ios 等等各种客户端,客户端做就重复劳动了。而且排序规则改变时,若干个端都需要改。
    当然排序这么简单的东西,谁做都一样。但是以后如果需要加分页了,那还是后端做,从扩展性上考虑,后端做比较好
    lihongjie0209
        27
    lihongjie0209  
    OP
       2019-07-02 13:38:04 +08:00
    @Chingim 没有多端, 所以暂时不考虑
    a62527776a
        28
    a62527776a  
       2019-07-02 13:43:24 +08:00
    这种应该是需求定的把 怎么能因为前端说组件不支持就要求后端改接口呢
    will0404
        29
    will0404  
       2019-07-02 13:44:00 +08:00 via Android
    @lihongjie0209 你的假设就是错的,接口不应该根据 UI 来定。既然你接口要根据 UI 来定,那么 UI 变了接口跟着变不是合理的吗?这个点在于,接口不是跟着前端变,而是接口和前端都跟着 UI 变了。
    a62527776a
        30
    a62527776a  
       2019-07-02 13:47:25 +08:00
    我感觉的问题是
    前端说组件不支持数组 所以要个树
    那不是应该前端自己找个支持数组的组件嘛
    lihongjie0209
        31
    lihongjie0209  
    OP
       2019-07-02 13:47:47 +08:00
    @will0404 我的意思是, UI 需要展示的数据我都发给前端, 至于说前端要展示 列表还是树状结构那是前端决定的. 就像前端展示 "2019 年 1 月 1 日" 或者是 "2019-01-01" 和我后端没关系
    OSF2E
        32
    OSF2E  
       2019-07-02 13:48:28 +08:00   ❤️ 1
    理论上说,交给前端来排序没有问题,但前提条件是 —— 由前端来决定什么时间请求数据以及如何请求数据。

    “前端做起来很费力”,只能说明交互场景设计、视图状态分析等等工作拆分的还不够细。

    换个角度说,不能用后端“少量字段抽象一个模型”的思路来处理前端问题,应当先分析交互流程,将一个完整的功能拆分为一系列静态场景,然后由前端提出后端数据接口的适配需求,也就是说实现一个功能可能需要提供多个接口,而不是后端把数据“一锅甩给前端,让前端自己在里面选有用的”。
    lihongjie0209
        33
    lihongjie0209  
    OP
       2019-07-02 13:48:40 +08:00
    @a62527776a 嗯, 前端组件需要什么数据结构肯定是前端自己处理, 现在和后端接口耦合了
    lihongjie0209
        34
    lihongjie0209  
    OP
       2019-07-02 13:49:42 +08:00
    @OSF2E 我说的费力是前端的组件需要一个树, 但是我给的是一个数组
    liuhuansir
        35
    liuhuansir  
       2019-07-02 13:50:32 +08:00
    @lihongjie0209 前端 UI 变,接口跟着变也是常事,再说就这两个例子又不复杂,后台跟着变也无关紧要吧,商量着来就行了
    Caballarii
        36
    Caballarii  
       2019-07-02 13:51:45 +08:00
    所以现在经常有一层 API 转发,通常是 node,拿着后端大而全的数据,变成更精细的数据接口给前端用,属于前端的活
    version
        37
    version  
       2019-07-02 13:51:59 +08:00
    推荐是前端转吧.我看像是后台管理的应用
    能减少后端的业务混乱才是好前端
    一对多.多对多.树形结构.后台管理本来数据量不大.没必要后端去拼接..
    前端都 vue react 有状态机了.很方便拼接的了.

    我一般是让前端改..不会写的.我会帮前端写.然后再喷他们菜.一个数据处理都不会的前端都是 lj
    所以前后端分离.不是一条心的..最终整个团队都是毒瘤了..接口数据拼接多.接口会忙.再加需求.后端抗不了的了

    如果是 app 的那些接口.就统一后端处理数据了...最好前端只做展示.包括日期
    zmyongfeng
        38
    zmyongfeng  
       2019-07-02 13:52:05 +08:00
    打得过就让他做。打不过就自己做
    lihongjie0209
        39
    lihongjie0209  
    OP
       2019-07-02 13:52:24 +08:00
    @liuhuansir UI 变的意思是在所需数据不变的情况下调整 UI, 最简单的例子 前端展示 "2019 年 1 月 1 日" 改为 "2019-01-01", 这种情况下接口是不需要改变的
    KingOfUSA
        40
    KingOfUSA  
       2019-07-02 13:53:30 +08:00
    前端做。
    unco020511
        41
    unco020511  
       2019-07-02 13:54:05 +08:00
    一般是后端处理,前端避免数据计算和整理
    lihongjie0209
        42
    lihongjie0209  
    OP
       2019-07-02 13:54:08 +08:00
    @version 这种数据处理工作 map reduce filter 直接解决, 没什么复杂性, 下次我直接帮前端写代码
    liuhuansir
        43
    liuhuansir  
       2019-07-02 13:54:15 +08:00
    @lihongjie0209 我能说前端展示 "2019 年 1 月 1 日" 改为 "2019-01-01",这种需求,我们的后端都愿意帮忙实现。。。可能是我们工作量都不饱和吧,人家愿意做,我总不能拦着吧
    lihongjie0209
        44
    lihongjie0209  
    OP
       2019-07-02 13:55:00 +08:00
    @liuhuansir ...........无话可说, 佩服佩服
    guorui112
        45
    guorui112  
       2019-07-02 13:56:19 +08:00   ❤️ 1
    看和后端关系好不好,以前和一个关系比较好的后端做项目,都是抢着做,看哪边处理方便
    OSF2E
        46
    OSF2E  
       2019-07-02 13:57:10 +08:00
    @lihongjie0209 锅背不动了,那就不背了
    version
        47
    version  
       2019-07-02 13:59:24 +08:00
    @lihongjie0209 如果是后台管理最好要喷喷前端的了.不行就自己改了..后端再转..以后合并其它数据更加难..例如 table 是 5 个连表出来的数据...一个单独的 tag.都需要我转字段给他们..我就要说了..这无疑会搞垮整个 sql..后端再转多一层分明就是业务乱了.以前试过..后台管理不能让前端做话事权..能前端转数据的是最有利于以后迭代的..
    15651980765
        48
    15651980765  
       2019-07-02 13:59:34 +08:00
    我司前端没人权,此类工作都是前端在做,后台大部分时间都是直接给全量数据,前端要啥数据,自己遍历去取然后拼成想要的格式,我已经不止一次吐槽过后台了,然并卵!
    will0404
        49
    will0404  
       2019-07-02 14:00:30 +08:00 via Android
    @lihongjie0209 你举的例子是两类问题。
    要列表还是要树,后端做。
    时间的格式,前端做(后端提供时间戳满足所有场景)。
    对于第一类问题我说了,你接口是根据 UI 定的,从列表换到树,想必 UI 变了吧?而且改动还不小,有什么理由不重写接口呢?
    举个例子,通常接口返回的数据会有一层数据校验,在后端某个中间件上,你不打算改接口,返回的旧数据,而数据转换放在了前端,那一层服务就形同虚设了。
    raynor2011
        50
    raynor2011  
       2019-07-02 14:01:56 +08:00   ❤️ 1
    和显示强相关的,必须前端做啊
    lihongjie0209
        51
    lihongjie0209  
    OP
       2019-07-02 14:02:13 +08:00
    @will0404 ui 变了, 但是数据还是那些数据
    527944441
        52
    527944441  
       2019-07-02 14:02:56 +08:00
    第一个谁做都行 第二个我觉得做之前应该商议一下
    Caballarii
        53
    Caballarii  
       2019-07-02 14:04:23 +08:00
    市场上彩笔前端太多了,培训班出来一点基本功都没有的,造成了都得后端帮忙的现状
    Sapp
        54
    Sapp  
       2019-07-02 14:07:30 +08:00
    第一个问题无所谓,第二个问题得看具体情况,如果就是这一份数据需要稍微转换一下,实际谁做都可以。但是如果这个结构涉及到很多接口的调用组合然后才能拼出来,那这个接口设计就有问题,也不存在谁做的问题了。
    TimPeake
        55
    TimPeake  
       2019-07-02 14:08:44 +08:00
    作为前端做过类似的。
    特别树形之类的复杂嵌套之类的数据,真的是后端做方便点。
    后端可能几行代码解决了。 前端却需要十几行甚至几十行代码去转换格式化成理想数据,可能还有 BUG

    总结:你把东西推给前端,工作流程没有错。但是出于道义,我建议你多为你的前端考虑一下
    lihongjie0209
        56
    lihongjie0209  
    OP
       2019-07-02 14:08:50 +08:00
    @Sapp 全量数据, 不存在调用多个接口的问题
    deleteDB
        57
    deleteDB  
       2019-07-02 14:09:23 +08:00
    第一个问题 后端做 如果有一天需要分页全表排序 前端是做不了的 还不如现在后端就做了
    第二个问题 谁做都可以 数据量大推荐后端做

    感觉没什么代码规范 要不然至少不应该有第一个问题

    我是前端
    lizz666
        58
    lizz666  
       2019-07-02 14:09:30 +08:00
    让我想起了上个项目,涉及到腾讯广点通区域定向和今日头条区域定向数据,这两个平台返回的数据结构并不一致,我前端有个树形结构,需要按我树形结构格式给我数据。
    头条的数据由于是死的,官方文档上有,我直接在前台写死处理好了。腾讯就比较 fuck 了,必须通过腾讯的接口才能拿到那么多数据,一开始,嫌烦,让后端帮我做,结果,数据太多,接口超时,后来实在没辙,还是交给我前台来处理了。
    keikeizhang
        59
    keikeizhang  
       2019-07-02 14:09:53 +08:00
    和 demo 操作没有关系的数据处理一律是后端的工作
    lihongjie0209
        60
    lihongjie0209  
    OP
       2019-07-02 14:11:05 +08:00
    @TimPeake
    同样的逻辑用 java 写和用 js 写代码量不会有太大的差距
    后端实现的唯一好处在于标准库比较丰富, 静态检查比较严格.
    lihongjie0209
        61
    lihongjie0209  
    OP
       2019-07-02 14:11:55 +08:00
    @deleteDB 第一个数据量是死的, 就几条
    tailf
        62
    tailf  
       2019-07-02 14:13:35 +08:00
    这些前端数据格式化的需求,理论上需要配一个 API 层来处理,这一层只负责给前端需要的数据做聚合和结构处理,这个是有后端工程师做的,但是却属于大前端的范畴。

    其实大多数常见的场景都很好办,上 GraphQL 规范,搞定。
    freakxx
        63
    freakxx  
       2019-07-02 14:18:52 +08:00
    这个问题其实主要看谁有空,谁方便,但有个平衡性

    如果是数据展示的问题可以考虑类似
    ?format=json or ?format=xml 这种方式

    如果数据是固定的,资源性的,那么考虑 /api/<api>/xxx/这种给他做个特殊化,比如
    /api/students-tree/ or /api/students/tree/
    15651980765
        64
    15651980765  
       2019-07-02 14:21:02 +08:00
    @lihongjie0209 话说请教一下数据量大的时候,放在前端处理,对页面性能会不会有什么影响?
    serge001
        65
    serge001  
       2019-07-02 14:26:21 +08:00
    我是前端,反正我觉得这些大部分情况下都应该在前端处理,为了处理数据格式没必要加多个 node 中间层...
    limuyan44
        66
    limuyan44  
       2019-07-02 14:28:39 +08:00 via Android
    解决问题最快的方法是让测试直接把 bug 提给你,这样不就不大费周章了。
    KingOfUSA
        67
    KingOfUSA  
       2019-07-02 14:46:20 +08:00
    因为有类似的问题,所以现在团队里面的前后端交互都是让后端的同事来负责(美名其曰 全栈),前端的同事负责做静态页面以及后端解决不了的问题。
    BreezeInWind
        68
    BreezeInWind  
       2019-07-02 14:46:38 +08:00 via Android
    我前后端都做,做前端的时候我就跟后端说数据随便给,我自己处理成合适的格式,只要别多余浪费就行,比如要五条给十条,要十个字段给二十个字段之类的;做后端提供接口的时候就找前端确认好要的结构,争取他们不怎么用写任何多余的处理逻辑就渲染出界面,。这件事怎么做感觉就是存乎一心,做有做的道理,不做也有不做的道理,如果有合适的机会,前后端都做一下,你会对这件事有不一样的感悟的
    Yuicon
        69
    Yuicon  
       2019-07-02 14:51:16 +08:00
    看了半天 就是一个扯皮的问题
    l00t
        70
    l00t  
       2019-07-02 14:53:24 +08:00
    当然应该前端做。这就是个前端显示的需求,跟后端有什么关系。
    coolooks
        71
    coolooks  
       2019-07-02 14:59:22 +08:00
    有时间来这里扯皮,没时间改接口,闲的蛋疼
    lihongjie0209
        72
    lihongjie0209  
    OP
       2019-07-02 15:01:27 +08:00
    @coolooks 接口早就写好了, 只是讨论一下这个问题而已
    lihongjie0209
        73
    lihongjie0209  
    OP
       2019-07-02 15:02:06 +08:00
    @Yuicon 是一个规范的问题
    rr41ns
        74
    rr41ns  
       2019-07-02 15:05:52 +08:00
    都是后端处理。
    rr41ns
        75
    rr41ns  
       2019-07-02 15:09:18 +08:00
    本人是后端,工作久了就知道沟通的成本很贵,只要是我力所能及能做的我就做。

    有时候排序是 sql 里加个 order 的事儿,后端不弄还要让前端去专门排序考虑数据正确性吗?

    有来回沟通的功夫早就弄好了,而且,这些活儿确实是该后端处理。
    drlalll
        76
    drlalll  
       2019-07-02 15:14:43 +08:00
    事实上很多前端只会做界面,逻辑非常差。所以一般逻辑问题都是后端处理好,当然你们这个问题属于沟通不畅。
    coang
        77
    coang  
       2019-07-02 15:15:04 +08:00
    如果是树后端做比较好.. 你排序问题 要加数据处理 而不是说前端要这个顺序接口就改成这个顺序.. 排序问题要对应有排序的参数... ps.我是后端
    zydxn
        78
    zydxn  
       2019-07-02 15:17:05 +08:00
    第一种情况,一般接口都有默认排序,如果业务需求上来回变化,走配置。
    第二种情况,如果需求变化,要求提供树,就再加个树接口。
    passerbytiny
        79
    passerbytiny  
       2019-07-02 15:22:03 +08:00
    @lihongjie0209 这个其实后端做也是可以的,后端可以在不动领域模型 /服务核心层的情况下,针对不同的前端、版本、特殊定制出不同的接口。传统的 Dao-Service-Controller 分层,如果正确的隔离 Service 层和 Controller 层,是很容易以很少的工作量来实现这种效果的。此时,接口由前端定义——但前端需要深入了解领域模型或业务模型。这样安排,对整体的好处是前后端之间更加松散。对后端的好处是:后端虽然没有了接口的主要控制权,但也没有了定义接口的责任。

    不过,以上只是一种可以选择的方式,而不是建议的方式,具体哪种方式,取决于架构师、技术委员会或者技术负责人,如果都没有,那就取决于前后端谁的话语权更大了。
    hyy1995
        80
    hyy1995  
       2019-07-02 15:22:12 +08:00
    其实这些个逻辑前后端都能写。但接口可能会多页面重复调用,如果是这样的话数据格式还是后端处理比较好
    tingfang
        81
    tingfang  
       2019-07-02 15:22:25 +08:00
    都可以,我觉得后端做更好一些,前端如果是 APP 或者小程序,逻辑改动还需要审核发布,后端做的话改起来会更方便些?
    santom
        82
    santom  
       2019-07-02 15:24:20 +08:00
    数据量不大 随便都可以吧 数据量稍微大点 还是后台做吧
    dicc
        83
    dicc  
       2019-07-02 15:26:10 +08:00
    用户量大的话,后端做就不好了
    Hakka
        84
    Hakka  
       2019-07-02 15:27:08 +08:00
    排序问题
    一般是我后端做
    数据整理问题
    一般是我后端做(同三楼)
    dongxiao
        85
    dongxiao  
       2019-07-02 15:30:32 +08:00
    看是否改动频繁吧,如果改动频繁前端做比较好点,不然每次调整页面都需要改动接口,如果基本定下来不会动了,后端改起来还是要快点,话说公司最近的一个项目包括页面显示的文字都是我这接口返回的,就是 No.1 xxxx No.2 xxxx 这种,前后端还是要多多配合,都是为了进度不是嘛
    zsy979
        86
    zsy979  
       2019-07-02 15:51:31 +08:00
    到底由谁做?没人能给最终结论
    我是后端前些时刚经历了因为数据结构问题跟前端扯皮。。
    树形结构转换在扯皮过程中都是小事,也算是头一次遇到糟心的前端可能他也是这么想的。
    现在好了没必要因为这种问题去扯皮,就算说服他让他转换又能怎样,他可能还会想这个煞笔这都不会或者这都懒得做
    x7395759
        87
    x7395759  
       2019-07-02 16:56:11 +08:00
    此时就需要多一个层了
    mmuggle
        88
    mmuggle  
       2019-07-02 17:07:09 +08:00
    GraphQL
    NotNil1
        89
    NotNil1  
       2019-07-02 17:07:17 +08:00
    树的话我一般每个节点会额外给一个排序字段,层级字段。
    xianxiaobo
        90
    xianxiaobo  
       2019-07-02 17:14:20 +08:00
    建议分成三个职位,一个后端,只做数据库的增删查改,一个前端,只做页面渲染,交互和样式书写,还有一个中端,专门做数据转换,将前端传入的数据转换为后端想要的数据,将后端返回的数据转换为前端想要的数据,以此解决此类扯皮问题。
    MoRun
        91
    MoRun  
       2019-07-02 17:37:30 +08:00
    这个得看情况
    如果你的后端很重,有很多任务要做,比方说后端是一个负载均衡的网关,或者需要对个多展示层,那展示层的数据需要给前端做,或者再加一层数据处理层来专门做这个事情,比如说 GraphQL
    如果你的后端仅仅只是简单的增删查改,我觉得还是尽量配合前端比较好
    CoCoMcRee
        92
    CoCoMcRee  
       2019-07-02 17:49:24 +08:00
    我这里 后端大多接口都会提供排序字段, 支持正反排序.
    最外层肯定是树形结构.
    {
    "success": true,
    "errorCode": "",
    "message": "",
    "data":

    }
    CoCoMcRee
        93
    CoCoMcRee  
       2019-07-02 17:51:13 +08:00
    data 里头才是前端要的数据
    而且 ,谁说只有后端才做数据校验

    我这里前端对后端返的数据也要做数据校验的哦, 不同接口,校验的字段和结构都不一样哦.
    bdnet
        94
    bdnet  
       2019-07-02 18:03:18 +08:00
    1. 问题不应该是 没有事先约定好接口数据结构?

    2. 业务逻辑尽量收拢在一个地方,也就是后端,后端可以加一成,处理数据转换
    yufeng0681
        95
    yufeng0681  
       2019-07-02 21:24:42 +08:00
    1、还缺个组长,定义接口数据按什么排序返回;
    2、后端做得越厚,前端就越简单,多个终端做起来一致性也容易保证。
    3、你想做得灵活一点,就让前端传排序参数,支持多种排序方法返回数据。
    petelin
        96
    petelin  
       2019-07-02 21:35:35 +08:00 via iPhone
    屁大点事 这都无所谓 当时文档怎么写的就怎么改

    后期需求就看谁的老板硬

    这都无所谓有什么好讨论的
    nidaye999
        97
    nidaye999  
       2019-07-02 21:44:54 +08:00
    后端做,这么弱智的问题
    a852695
        98
    a852695  
       2019-07-03 01:58:15 +08:00
    尽量后端做,前端核心是交互和数据可视化,你非觉得 chrome 性能好到比你服务器还快,那你就前端做吧
    a86356
        99
    a86356  
       2019-07-03 06:22:21 +08:00 via iPhone
    后端做,数据结构后端做,给前端需要的数据结构即可。前端也一样的,提交数据的时候给你需要的数据结构。没什么好说。前端主要是交互。而且排序什么的,后端处理一 order 的问题,前端做还要遍历再排序,浪费时间。前端要做的是一些小的数据转换显示,比如时间搓,一些状态,1.2.3 转成对应文字。
    a86356
        100
    a86356  
       2019-07-03 07:53:19 +08:00 via iPhone
    @hedamao9999 说的很对,都做过考虑会比较周全。要不然一叶障目
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3075 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 44ms · UTC 12:50 · PVG 20:50 · LAX 05:50 · JFK 08:50
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.