树形数据前端生成还是后台生成返回比较好?

树形数据前端生成还是后台生成返回比较好?

阅读 7.6k
8 个回答
  1. 通常来说 生成树形结构 的处理过程放在后端是更合适的,数据量大的情况下,后端能将数据成最终状态是最理想的,前端请求数据已经经历了一次耗时的 http,如果请求到数据还需要做 结构 上的处理的话显然不太合适:

    • 虽然这种处理两个端都可以做,但我们编写程序都知道逻辑要内聚,一次数据处理中的多个处理函数,最终应该内聚到一个 api 中,需要时向外提供这个 api 即可。这种思考方式放在这里同样适用,后端负责提供数据,那么关于数据处理的过程应该内聚在后端
    • 另一个角度,假设后端不转,但这些数据最终都需要以树形结构展示,那么每个对接这个接口的前端都需要做一次数据转换,这其实是不必要的资源浪费
  2. 结合当前主流的前端UI框架来看,前端拿到 树形数据 后肯定还需递归做一次 节点属性 的转换,比如树节点的业务字段是 id,title 等,不同的 UI 框架的树组件可能需要的又不一样,但适配属性的开销肯定是小于结构转换的,这部分处理放在前端问题不大,也更灵活

树形数据生成,存在这样的需求,通常是因为数据库是以线性表的形式保存数据,通过 parent 关系来记录树形结节关系;而前端呈现的时候需要把它转换成结构化的树形数据。

那么从数据库到前端组件,经过了哪些处理过程呢?最简单的情况:

  1. 后端应用把数据从数据库读取出来,处理并交给前端
  2. 前端对数据进行进一步处理呈现出来

也就是简单的前/后端两个点。这两个点都可以做线性数据向结构化数据的转换,所以有此疑问到底该在哪里做?

在没有任何提效机制的情况下,后端做就意味着每一次请求(单指需要树形的),都需要去进行一次转换,如果有 1 万次请求,就要做 1 万次转换,服务器要承担这 1 万次计算负担。如果把这个转换过程放前端,实际会把这 1 万次请求产生的转换分散到每个客户端(浏览器)去,我认为可以简单的计算为:服务器性能要有客户端性能的 1 万倍才能达到相同的时间效果。

当然实际上不会产生这么大的差异,

  1. 前端不是拿机器性能来跟服务器进行比较,而是浏览器对这一个应用所分配到的性能。这个差距本身确实就很大的。
  2. 服务器通常会有一些缓存和加速重算的机制,实际并不会对每一个相同的请求都再去算一次。何况对同样的请求,浏览器还有缓存机制。
  3. 如果前端本身就需要对数据进行进一步加工,直接在前端合并处理,可能会减少一次处理过程。

这么说来,其实有很多点是可以做优化的。

  1. 服务器加缓存,提前生成树形结构缓存起来,每次客户端请求都直接返回缓存内容。这种方式不适合每次请求的树形数据大不相同的情况
  2. 浏览器缓存,在相同 URL+QueryString 的情况下,浏览器会自动缓存请求到的数据。这种情况下需要服务器响应的数据是已经处理过的。如果前端处理就不能利用这层缓存。
  3. 前端使用 LocalStorage 等手段缓存,实际会减少数据的请求,这种情况下服务器返回处理前/后的数据其实不重要。
  4. 如果真的都到了生产树形结构数据需要特别在意的情况下,应该考虑懒加载,即展开节点的时候再去请求 1~2 层的数据。
  5. 如果数据都复杂到“换人”就可能产生不能理解业务的程度……前端处理和后端处理都解决不了这个问题,这个问题只有详尽的文档能解决。当然带类型的代码本身具有较强的自解释能力,所以强类型后端似乎更合适,不过后端也不非强类型语言,前端也有像 TypeScript 这样的类型化语言,所以这点并不是选择前/后端解决的关键。

结论……没有结论,不存在一定的哪一端处理更好,需要根据实际情况去分析优化。如果只是纯粹的想划分责任……那就看谁比较空吧。

个人倾向前端做,后端传列表。如果前端显示方式变了,不需要后端同步做修改。

  1. 考虑团队水平,或者压力,前端水平高/压力小 就前端处理,反之后端
  2. 总体来说考虑后端,因为后端有类型(默认前端不用ts,后端不用map或者jsonObj),处理数据更容易一些

我感觉还是前端处理,一般后端返回list就可以,因为我觉得前端需要的类型可能多样的,就算一个页面,不用的地方都可能需要不同结构类型

还是前端处理更加灵活点,但都是得看前端的能力,如果能力不足还是让后端处理吧

别讨论了,现实情况基本是是谁吵架厉害听谁的。

前后PK, 谁赢了结构以谁为准.

其实就是看水平. 一般来讲, 前端水平不如后端.

推荐问题
logo
极客观点
子站问答
访问
宣传栏