关于后端:不好的编程习惯之列表保存

场景

置信大家工作中应该都有遇到过 表单内蕴含列表数据 的状况。如下图，一个出差申请单里同行人员是能够填写多行的。

首次保留是新增场景，间接 insert 即可。
如果容许对表单进行编辑批改，不少程序员的做法是先将数据库里的数据全副删除后，再从新 insert。
例如，首次保留后数据库的数据是

再次编辑时，即便什么都没批改，间接点击保留。因为代码里是先删除再插入，那么 id 会从新生成。数据库里的数据最终会变成

明确我意思了吗？尽管界面上用户看到的还是张三李四，然而数据库里的 id 曾经变了。

问题

小伙伴反诘我，尽管 id 是变了，然而用户看到的数据没变呀，业务含意也没有变呀，业务上又不关注它的 id，有什么问题呢？
真的没有问题吗？
思考下这个场景。假如这张单有 2 集体在同时操作，
小 A 把 张三 删除了，同时新增了 王五 ；
小 B 把 李四 删除了，同时新增了 赵六 。
按删除再插入 的实现，那么最终的后果受小 A 和小 B 的解决程序影响，后者会把前者的操作给笼罩掉，数据库里的数据最终要么是小 A 提交的 李四 + 王五 ，要么是小 B 提交的 张三 + 赵六 。
然而在业务含意上，在小 A 和小 B 的视角里，他们会很困惑。
小 A 会想，我明明新增了 王五 ，是没有保留胜利呢？还是谁把我的数据删了？
小 B 也会感觉委屈，我可素来没有看见过 王五 ，更别说删除 王五 了。

解决

正确的形式是什么呢？
新增、编辑、删除离开解决。
我刚提出的时候，小伙伴大叫，那要从数据库里取出来一一比照，好麻烦呀。
我提了 2 个点。
首先，业务须要的是正确的答案。你一秒就计算出了 338483893 * 95858328 = 3，的确很快，但后果是错的呀。你写了个简略的计划，却得不到业务想要的后果，简略又有什么意义呢？
其次，谁说没有简略的计划？

参考实现

还以小 A 的操作为例，假如初始数据是

小 A 删除了 张三 ，新增了 王五。那么在接口传递的时候，客户端向服务器段发送的数据能够是

[{id: 1, name: '张三', deleted: true},
  {id: 2, name: '李四', deleted: false},
  {id: null, name: '王五', deleted: false},
]

那么服务器在收到申请后，别离解决删除、新增、删除

for(UserDto userDto: users){if(Boolean.True.equals(userDto.deleted)){
       // 删除
       delete(userDto);
    }else if(userDto.getId() == null){
       // 新增
       insert(userDto);
    }else{
       // 更新
       update(userDto);
    }
}

别纠结我在 for 循环里操作数据库，也别纠结我间接把 dto 传给 delete、insert 等，本文的重点不在这。

后果

回到本文结尾的例子，小 A 和小 B 在各自点击保留后，看到界面上的数据从 张三 + 李四 变成了 王五 + 赵六 ，然而却不会对他们造成困惑。
比方对小 A 来说，张三删除胜利了，王五新增胜利了。
至于隐没的李四和忽然呈现的赵六，小 A 一问，是你删掉李四和新增赵六了？小 B 答，是的。