1

我正在将核心数据与服务器请求相结合的应用程序中重写一大段代码。我正在尝试找出最好的解决方法，以便在新的服务器请求返回新的 JSON 时，我可以同时更新对象。顺便说一句，如果 iOS7 使解决方案变得更好，请随意假设代码只需要与 iOS7 兼容。

这是一个基本用例：

假设我有一个具有和属性以及 2 个 M2M（用户/用户）关系的User实体：嗯... ？当然。idnamefriends.fiends

所以应用程序启动。内存图和 SQL 持久存储中都没有任何内容。我要求检索 id 为 15 的用户及其朋友和恶魔。

接下来发生的是：

  1. CDUser使用 type 的谓词进行fetch on id = 15。
  2. 什么都没有返回，因此它为以下服务器端点排入 3 个 AFRequest：A：（ /users/15这将获取用户属性，id和name）、B：（ users/15/friends关系）和C：（ users/15/fiends关系）。这 3 个请求是并发的。
  3. 在任何这些请求返回的那一刻（使用用户的 JSON 表示或关系的朋友/朋友数组），我查询 CD 上下文以查看 JSON 有效负载中的任何对象是否已存在于 CD 中。如果确实如此（这将在随后的服务器调用中发生），我会使用来自服务器的任何新数据更新它们（包括在适用时建立关系）。如果不是，我在 CD 上下文中创建一个新的托管对象，并从 JSON 填充属性/关系。在这种情况下，对象的创建和识别始终基于其id属性。
  4. 无论哪种方式，当我完成后，我会保存 CD 上下文。

综上所述，每次 JSON 从服务器返回时，我都会创建或更新相应的托管对象并保存。对于此示例，问题在于，相同的上下文将获得 3 个潜在的并发调用：创建用户 15 和/或填充其friends，创建用户 15 和/或填充其fiends，创建用户 15 和/或更新其名称和 ID。

我原来的计划是：

  1. 一个接一个地制作 3 个 AFRequest（我假设它进入并发队列，因此将同时执行）
  2. 将请求的完成块全部分派到同一个 GCD 并发队列中。
  3. 让每个 GCD 块创建一个新的 CD 上下文，进行插入/更新，然后调用 save
  4. 让主 CD 上下文合并主线程中的更改。

但是现在我刚刚阅读了一些关于 a 的两种队列并发类型NSManagedObjectContext以及-performBlock:子上下文的概念，但我还没有完全理解。所以我想知道，我原来的计划听起来可行吗？

我能想到的几个问题是：

  • NSPrivateQueueConcurrencyType相反，对于第 3 步，为每个 GCD 块创建主上下文的子上下文是否更好？
  • 如果是这样，我什至还需要 GCD 队列吗？也就是说，我是否应该使用单个上下文NSPrivateQueueConcurrencyType而不是通过 GCD 调度，只是这样做-performBlock:？
4

0 回答 0