ios - 核心数据架构

Question

关闭。这个问题需要更多 focused .它目前不接受答案。












想改进这个问题？更新问题，使其仅关注一个问题 editing this post .

6年前关闭。




Improve this question




我正在开发一个已经实现 Core Data 的 iOS 应用程序。所以我无法从头开始理解核心数据的实现。但我可以在添加新功能的同时处理 Core Data。但我对 Core Data 有很多疑问。我无法从任何博客中找到明确的想法。

1) 问题 1 - 我已经设置了应用程序的体系结构，它具有 Web 服务 Controller 类、Web 服务帮助器类、DatabaseManager 类、UiViewController 类和模型对象作为核心数据的一部分。

Web 服务 Controller 使用 NSURLConnection 和其他相关功能连接到服务。一旦从 Web 服务获得响应，它就会使用 block 向 Web 服务帮助器类提供回调。

Web 服务处理程序类有助于从所有 UIViewController 调用服务。 Web 服务助手类作为中间类在 UIViewControllers 和 Web 服务 Controller 之间建立 Web 服务。因此，当 Web 服务助手从 Web 服务 Controller 获取回调时，它会在 block 的帮助下将响应发送回 UIViewController。

我的问题在这里，将 Web 服务响应存储到核心数据以及更新 UI 中的数据应该是什么流程。我想知道这样做的最佳做法。我应该将数据保存到核心数据中，然后检索并在 UI 中显示吗？但是如果数据很大，保存数据需要时间。核心数据操作和更新 UI 应该同步。

2) 问题 2 - 我在许多博客中阅读了有关 Core Data 操作并发性的内容，但我对 Core Data 中的并发性还不是很清楚。

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

3) 问题 3 - 由于我们可以创建多个 moc，那应该是 NSConfinementConcurrencyType 并在所有 doc 上执行 performBlock 以实现并发吗？

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

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

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

任何人都可以回答以上问题吗？

提前致谢。

Answer 1

这确实应该是几个单独的问题。我将尝试回答架构问题，并可能涉及其他一些问题。

Web 服务的返回路径不应直接到达任何 View Controller 。您的服务助手解析响应并验证它的位置是您要保存到核心数据的位置。这个任务应该交给另一个类(class)。

从 View Controller 端，您想使用 NSFetchedResultsController s (FRCs) 以了解模型何时更改。您可以设置 FRC 来观察任意数量的对象，包括单个对象。

FRC 旨在用于 TableView ，并且有许多示例可用于说明如何将它们用于此目的。例如，如果您有一个正在编辑单个对象的 View ，并且您使用 Web 服务来保存更新，那么您可以有一个 FRC 正在监视已编辑的对象。保存完成后，FRC 将触发，您可以更新 UI 以指示成功，或其他。

核心数据

正如您所发现的，Core Data 并发并非微不足道。我对以下设置有最好的体验:

带有 NSMainQueueConcurrencyType 的只读上下文.这是绑定(bind)到持久存储的初始上下文。此上下文在整个 session 中保持不变。

一个 NSOperationQueue并发性为 1。此队列上的操作克隆主(只读)上下文，并发类型为 NSConfinementConcurrencyType , 并连接到同一个商店。只允许保存这些克隆的上下文。当操作完成时，这些上下文将被丢弃。

将更改合并到主上下文中的合并处理程序。

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

View Controller 和其他主线程事件使用始终存在的主上下文。

还有很多其他设置，包括多个可写的 sibling 、父子关系等。我建议选择简单的，因为您不想同时与核心数据和线程问题作斗争。

推荐观看this video保罗·戈拉克。我喜欢的堆栈的灵感直接来自 Paul 的演示文稿。