核心数据结构

Question

我正在开发一个核心数据已经实现的iOS应用程序。因此，我无法从零开始理解核心数据实现。但是我可以在增加新功能的同时处理核心数据。但我对核心数据有很多疑问。我从任何一个博客上都找不到清晰的想法。

1) 问题1 -我已经设置了应用程序的体系结构，其方式是将Webservice控制器类、Webservice助手类、DatabaseManager类、UiViewController类和模型对象作为核心数据的一部分。

Web控制器通过NSURLConnection等相关功能实现与服务的连接。一旦响应从web服务获得，它就会通过块对Webservice助手类进行回调。

Web服务处理程序类帮助从所有UIViewControllers调用服务。UIViewControllers类充当在UIViewControllers和Web服务控制器之间创建web服务的中间类。因此，当web服务助手从web服务控制器获得回调时，它会在块的帮助下将响应发送回UIViewController。

我的问题是，应该如何将web服务响应存储到核心数据以及更新UI中的数据。我想知道这样做的最佳做法。我是否应该将数据保存到核心数据中，然后在UI中检索和显示？但是，如果数据很大，保存这些数据将需要时间。应该同步地进行核心数据操作和更新UI。

2) 问题2--我在许多博客中读到过关于核心数据操作并发性的文章，但是我对核心数据中的并发性还不太清楚。

据我所知，为了实现并发，我们必须创建两个managedobjectcontext，一个使用NSMainQueueConcurrencyType，另一个使用NSPrivateQueueConcurrency。然后，所有的保存和更新操作都必须在privateMOCNSPrivateQueueConcurrencyType中执行，读取操作可以用mainMOCNSMainQueueConcurrencyType执行。这个操作与performBlock有什么关系？

3) 问题3 -，因为我们可以创建多个moc，应该是NSConfinementConcurrencyType并在所有文档上执行performBlock以实现并发性吗？

4) 问题4 -问题2和问题3中提到的实现并发的区别是什么？

5) 问题5 -考虑，我正在使用核心数据读取记录，由于并发性，相同的记录必须更新一个值。如何处理这种情况。我在这里知道的是，我必须使用合并策略。但我不知道如何实施，因为我对上述情况并不清楚。

6) 问题6 -在应用程序中，可以创建多少类型为NSMainQueueConcurrencyType、NSConfinementConcurrencyType和NSPrivateQueueCOncurrencyType的managedobjectcontext？

有人能回答上面的问题吗？

提前谢谢。

Answer 1

这应该是几个单独的问题。我将尝试回答架构问题，也许还会触及其他一些问题。

web服务的返回路径不应直接到达任何视图控制器。您的服务助手解析了响应并对其进行了验证，这就是您想要保存到核心数据的地方。这个任务应该交给另一个班。

从视图控制器端，您希望使用NSFetchedResultsController(FRC)来了解模型何时发生了更改。您可以设置一个FRC来监视任意数量的对象，包括单个对象。

FRCs是为表视图设计的，关于如何将它们用于表视图，有许多可用的示例。例如，如果您有一个编辑单个对象的视图，并且使用web服务保存更新，则可以有一个监视已编辑对象的FRC。当保存完成后，FRC将触发，您可以更新UI以表示成功或其他任何东西。

核心数据

正如您已经发现的那样，核心数据并发性并不简单。我有过以下设置的最佳经验：

• NSMainQueueConcurrencyType的只读上下文。这是连接到持久存储的初始上下文。在整个会议上，这种情况仍然存在。
• 并发性为1的NSOperationQueue，此队列上的操作克隆主(只读)上下文和并发类型的NSConfinementConcurrencyType，并连接到同一存储区。只允许保存这些克隆的上下文。当操作完成时，这些上下文将被丢弃。
• 将更改合并到主上下文中的合并处理程序。

操作在后台线程上执行，并且是同步的。这使得合并变得简单。克隆上下文是使用NSMergeByPropertyObjectTrumpMergePolicy的合并策略来设置的，主上下文是用NSMergeByPropertyStoreTrumpMergePolicy设置的。

视图控制器和其他主线程活动使用总存在的主上下文.

还有很多其他的设置，包括多个，可写的兄弟姐妹，父子关系等等。我建议选择一些简单的东西，因为你不想同时解决核心数据和线程问题。

我推荐看保罗·戈拉克的这段视频。我喜欢的堆栈的灵感直接来源于保罗的演讲。