Inline Editing — Bulk Update with Apex

同学们，今天我们来看一个非常实用的技巧：在 Lightning Web Components 里面，怎样一次更新多条记录，并且确保它们像绑在一起一样，要么全成功，要么全失败。这在处理像订单和订单行项目这种必须保持数据一致性的场景时，特别重要。 想象一下，你的页面上有一个数据表格，用户可能同时修改了好几行，然后点了一个“保存”按钮。如果你用一条一条单独更新的方式，比如多次调用 `updateRecord`，它们都是各自独立的事务。一旦中间某条因为验证规则失败了，前面已经成功保存的记录可不会自动退回去，数据就不一致了。 那更好的做法是什么呢？我们可以把这些要保存的变动，也就是 `draftValues`，一次性打包发给一个 Apex 方法。这个 Apex 方法收到的是一个 JSON 字符串，它会把它反序列化，还原成 sObject 的列表，然后执行一个单独的 DML 更新语句。因为是一个 DML 语句，Salesforce 会自动把它当作一个整体的事务。如果里面任何一条记录触发了验证错误，整个操作就会回滚，之前所有的更改都不会被保存。这就叫事务完整性。 在前端 JavaScript 这边，Apex 方法调用成功后，我们不能只是简单刷新数据。因为 Lightning Data Service，也就是 LDS，自己维护了一套缓存。我们需要告诉它：“嘿，你看一下这些记录，我已经在后台更新过了，你缓存的旧数据要清掉。” 怎么做呢？我们先调用 `notifyRecordUpdateAvailable`，把更新过的每条记录的 ID 传过去，LDS 就会标记这些记录需要重新从服务器获取。然后，如果我们页面上用的是 `wire` 来获取数据，还得再调用一次 `refreshApex`，把有线数据重新加载一下，这样表格里的信息才会是最新的。 总结一下，这种批量更新的 Apex 方法，相比一条一条独立更新，多了打包 JSON、调用 Apex、再通知缓存和刷新数据的步骤，但换来了一个核心保障：无论你有两条还是二十条相关记录要一起改，只要有一处不通过，全都恢复到未改之前的状态。这能帮你避免很多数据错乱的问题。 好了，今天的知识点就讲到这里，大家可以在课后试着在组件里实现一下，体会事务完整性的好处。