背景
最近在做课程后台开发时，遇到一个很有意思的问题。问题是这样的，有多节课程，运营人员可以根据需要调整课程的先后顺序，从而更改课程的展示顺序。
接到这个需求，立刻就想到了以前做首页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，以数组的形式发送给后端。数组的索引序号，则表示元素当前的排序。
后端实现逻辑：
- 删除不存在前端数组中的ID。将前端
ids，与服务器端的ids进行对比。删除服务器端存在但前端不存在的ids。 - 按照数组的排序，更新所有元素排序。
总结，此方法仅适用于排序元素较少（例如，总元素为5~15个）的场景。对于大量数据排序并不适用，适合首页轮播图管理、任务卡片管理。leangoo 的看板卡片管理就是采用这种方式。
方法二 取中值法（推荐）
原理与实现步骤：
- 创建元素时给元素赋默认位置（
pos字段记录该值）。赋值规则为，当创建第一个元素时，默认位置赋值为65536，第二个元素为265536=13172，增加第N个元素时，位置赋值为N65536。 - 当拖拽改变元素位置时，更新
pos。更新规则如下：
- 调整一个元素到两个元素中间时，
(pre_item.pos + after_item.pos）/ 2 = pos - 调整一个元素到第一个元素时，
old_first_item.pos / 2 = pos - 调整一个元素到最后一个元素时，
old_last_item.post + 65536 = pos
- 当前后两个元素的数值，不满足整数时，更新所有元素的排序。依次给每个元素的
pos赋新值。例如，第一位赋值65536，第二位为265536，第N位赋值N65536。
通过取中值的方法，改变元素的位置。当需要按序获取时，只需要对 pos进行排序，就可以获取元素的位置。
关于中值重排的问题，解决方法有多种。例如，我们可以使用浮点数储存 pos，但是需要考虑数据库存储的精度问题。而且，数值过小，会在前端丢失精度，元素排序会出现问题。当然，如果在接口层，当检测到中值过小，则对所有元素进行重排，接口相应速度会存在问题（如果是后端管理系统就不用考虑性能问题了）。
有人提出，利用定时任务每天对所有元素定时重排，来解决单次接口的性能问题。个人觉得这个方法，还是存在问题。若定时任务不及时，那么排序由于精度问题，发生了排序错乱的问题。那么，定时重排已经无意义。
方法三 单表单列
每个元素，都有一个字段index，表示元素的排序信息。
规定元素从0开始递增。
基本操作如下：
- 增加数据。 新增元素时，序号为当前元素数据总量值。
- 删除元素。删除元素时，将大于该元素的序号，都减1。
- 修改元素排序。当元素从 x 移动到 y 时，
- 若 x < y 时，则将(x, y)范围内的元素都减1
- 若 x > y 时，则将(y, x)范围内的元素都加1
- 查询元素。展示列表时，按照
index字段进行排序即可。若需要查第n位元素时，元素位置为index = n - 1。
这种方式优点是，查询快，修改慢。而且，修改接口的逻辑较重，处理起来比较麻烦。我们很多项目都是采用这种模式。在接口设计方面，我们让前端传给后端是一个偏移值（offset），offset = y - x。当元素向排序大的方向移动时，offset的为正值；若往排序小的方向移动时，offset`为负值。
总结
在选择具体方案时，还需要根据具体的业务场景选择。方案的选择规则总结如下：
- 若排序元素较少，采用方案一；
- 若排序移动次数不是非常频繁且对接口性能要求高，建议采用方案二；
- 若排序移动非常频繁且接口性能要求不高，可以采用方案三。
网友评论