Ember SPA删除关联模型时如何同步客户端与服务端数据

场景背景 #

我们开发食谱类Ember单页应用时，初始定义两个GET接口/ingredients/、/recipes/，分别映射Ingredient、Recipe两类数据模型：

• Recipe 由若干Ingredient及对应食材用量组成
• Ingredient 模型仅包含名称字段
  只要遵循JSON API规范，借助Ember默认的模型、序列化器、适配器即可轻松完成模型数据填充。

后端采用Django实现，配置了数据库级联删除规则：当某条Ingredient数据被删除时，数据库会自动删除所有关联该食材的Recipe数据。客户端执行Ingredient删除通常有两种写法：
第一种写法：

ingredient.deleteRecord();
ingredient.get('isDeleted'); // => true
ingredient.save();

第二种写法：

ingredient.destroyRecord();

核心问题解答 #

1. Store内关联Recipe的更新方式选择 #

两种可选方案的优劣势非常明确：

• 完全不推荐手动在客户端复现服务端级联删除逻辑。这种方案维护成本极高，一旦后端调整级联规则、或者存在其他服务端侧的关联数据变更逻辑，客户端很容易出现状态不一致，还会遗漏多用户同时操作等边缘场景的处理。
• 操作完成后重新拉取关联列表数据是实现成本更低、可靠性更高的选择。

首先要明确：Ember的路由、Ember Data没有原生提供模型依赖感知、自动拉取关联最新数据的能力，不会因为删除了Ingredient就自动更新Store中关联的Recipe记录，必须手动触发同步逻辑。

2. 常用的同步实现方案 #

可以根据业务场景选择适配的实现方式：

• 路由级刷新：删除Ingredient的请求完成后，调用当前路由的refresh()方法，重新触发路由的model钩子拉取最新的Ingredient、Recipe列表数据，适合删除操作发生在列表页的场景，代码量最小。
• Store定向刷新：删除操作完成后，调用this.store.query('recipe', 原有列表查询参数)主动拉取当前页需要展示的最新Recipe列表，新数据会自动同步到Store，所有引用Recipe数据的模板、计算属性会自动完成更新。
• 响应体优化：如果后端遵循JSON API规范，可以在删除Ingredient的DELETE接口响应中，通过included字段附带返回被级联删除的Recipe标识，Ember Data默认序列化器会自动将这些被删除的记录从Store中清理，不需要额外发起列表拉取请求，这种方案性能最好，但需要后端配合调整返回结构。

3. 前后端状态同步的标准实践 #

不需要每次操作后拉取全量相关数据，按场景选型即可：

• 如果是强一致性要求的后台管理类系统，操作完成后只需要刷新当前页面可见范围内的关联列表数据即可，不需要拉取全量所有关联数据，平衡一致性和性能。
• 如果是普通C端应用，对短暂的状态不一致容忍度较高，可以在用户下次进入食谱列表页时再拉取最新数据，不需要在删除食材后立刻触发Recipe数据刷新。
• 永远不要在客户端硬编码服务端的数据级联、校验类业务规则，服务端返回的状态是唯一可信源，客户端只负责做状态同步，避免两端逻辑不一致引发的隐性bug。

内容的提问来源于stack exchange，提问作者Evren Bingøl