后端之路

拖拽排序后端设计与实现

2018-09-19  本文已影响436人  youthcity

背景

最近在做课程后台开发时,遇到一个很有意思的问题。问题是这样的,有多节课程,运营人员可以根据需要调整课程的先后顺序,从而更改课程的展示顺序。

接到这个需求,立刻就想到了以前做首页banner轮播图的管理后台。轮播图中每一张图有先后顺序之分,为了进行图片排序,在设计banner实体时,设计了一个 weight (权重)字段。然后,让运营人员给每张图填写1~500值,值越大,则排序越靠前。由于轮播图展示的图片有限(不超过5张),即使通过人工填值的方式管理顺序,也不是很麻烦。但是,这种填权重管理顺序的方式不适用于数据量较多的课程管理。那么,如何解决这种排序问题呢?

为了解决元素自定义排序问题,我们想了很多解决办法。例如,

最后,综合考虑了一下,认为第四种最符合日常操作的习惯。针对拖拽排序进行了后端方案设计。

拖拽排序前端效果

需求描述

解决办法

方法一 全量更新元素位置法

适用场景:排序元素数量较少

原理:每个元素拥有一个字段,表示元素当前排序的位置。通过前端排序,将排好的元素位置,一次性发送到后端。然后,后端统一更新所有元素的位置。

具体实现

实体设计:增加排序字段 sort,表示元素当前的位置。例如,sort = 1,则表示元素处于第一位。

接口设计:

// 排序接口
POST /courses/sorting

// 格式:JSON
// 数组中为元素的ID
// 元素在数组中的序号,表示了元素的位置
// 例如,ID为3的元素,排序为 1,ID为2的元素,排序为2
[3, 2, 4, 1]

前端逻辑:当前端排序后,或删除元素后,将剩余元素ID,以数组的形式发送给后端。数组的索引序号,则表示元素当前的排序。

后端实现逻辑:

总结,此方法仅适用于排序元素较少(例如,总元素为5~15个)的场景。对于大量数据排序并不适用,适合首页轮播图管理、任务卡片管理。leangoo 的看板卡片管理就是采用这种方式。

方法二 取中值法(推荐)

原理与实现步骤:

  1. 创建元素时给元素赋默认位置(pos字段记录该值)。赋值规则为,当创建第一个元素时,默认位置赋值为65536,第二个元素为265536=13172,增加第N个元素时,位置赋值为N65536。
  2. 当拖拽改变元素位置时,更新 pos。更新规则如下:
  1. 当前后两个元素的数值,不满足整数时,更新所有元素的排序。依次给每个元素的 pos赋新值。例如,第一位赋值65536,第二位为265536,第N位赋值N65536。

通过取中值的方法,改变元素的位置。当需要按序获取时,只需要对 pos进行排序,就可以获取元素的位置。

关于中值重排的问题,解决方法有多种。例如,我们可以使用浮点数储存 pos,但是需要考虑数据库存储的精度问题。而且,数值过小,会在前端丢失精度,元素排序会出现问题。当然,如果在接口层,当检测到中值过小,则对所有元素进行重排,接口相应速度会存在问题(如果是后端管理系统就不用考虑性能问题了)。

有人提出,利用定时任务每天对所有元素定时重排,来解决单次接口的性能问题。个人觉得这个方法,还是存在问题。若定时任务不及时,那么排序由于精度问题,发生了排序错乱的问题。那么,定时重排已经无意义。

方法三 单表单列

每个元素,都有一个字段index,表示元素的排序信息。
规定元素从0开始递增。
基本操作如下:

这种方式优点是,查询快,修改慢。而且,修改接口的逻辑较重,处理起来比较麻烦。我们很多项目都是采用这种模式。在接口设计方面,我们让前端传给后端是一个偏移值(offset),offset = y - x。当元素向排序大的方向移动时,offset的为正值;若往排序小的方向移动时,offset`为负值。

总结

在选择具体方案时,还需要根据具体的业务场景选择。方案的选择规则总结如下:

参考资料

上一篇下一篇

猜你喜欢

热点阅读