示例用例：我们有一个可以更改状态（已读/未读）的消息列表。新消息可以出现在列表的任何位置，也可以在本地或通过其他方式从后端删除消息。
我们现在实现这一点的方式是，我们使用 SQLBrite 作为我们所知道的本地数据缓存的包装器。
- 操作（删除、更改消息状态）通过网络发送远程 API 调用来完成，或者我们轮询后端以查看是否有任何更改。
- SQLBrite 缓存作为远程 API 调用结果的副作用进行更新，包括用户发起的操作和定期轮询更新。此时，我们确切地知道发生了什么变化，我们执行 INSERT、UPDATE 或 DELETE 来更新缓存。
- UI 观察者被告知重新执行消息表的 SQLBrite 查询，并且 UI 更新自身以响应本地缓存中的更改。例如，使用挂起的删除动画离开一条消息。
问题是，处理第 3 步的最佳方法是什么？我们只剩下对新消息、已删除消息和更新消息进行昂贵的搜索了。我们必须运行整个查询，建立一组消息 ID，然后将其与我们在 UI 模型中知道的消息 ID 进行比较。当我们确切地知道 UI 小部件中需要更新的内容时，我们正在重建我们在第 2 步中获得的信息，但该信息并未在第 3 步中传递给我们的观察者。
有没有更好的方法来构建它，这样我们就可以避免代价高昂的对账步骤？