ios - 核心数据考验

Question

几周前，我决定为我的新项目学习 Core Data 并将其应用到我的整个模型中。有一个陡峭的学习曲线，但最终我熟悉了堆栈，现在我至少对基本概念和一些常见的陷阱(如线程并发)相当满意。

我不得不说，适应后的最初几周非常令人惊奇。 NSFetchedResultsController为您提供了一种在我的模型和 Controller 之间进行通信的好方法。然而，我使用 Core Data 的次数越多，它就越烦人。

作为一个具体示例，我的应用程序从我的服务器(帖子)获取一些出现在提要中的数据。每个帖子都有一个所有者，类别为 User ，我也从服务器获取。现在，核心数据非常适合管理帖子和用户之间的关系。该关系会自动更新，获取帖子的来源就像调用 post.owner 一样简单.但也存在不便之处:

1.Core Data 将我不希望强制到磁盘的对象强制到磁盘。这可能是主要问题。对于这些帖子，我不希望它们被强制写入磁盘，而宁愿再次调用服务器。为什么？因为我持久存储的帖子越多，需要做的家务工作就越多。帖子可以被编辑、删除、标记等...并且将这些帖子保留在本地意味着必须计划更新。

2.必须不断担心上下文、对象等的并发性。我写了一个对象工厂，它总是在正确的线程和正确的上下文中返回对象，但即使这样，错误也会时不时地出现，这很快就会变得令人沮丧。

3.性能下降。从缓存对象到核心数据，这可能是目前最不重要的一个，它对我的​​应用程序(最显着的是提要)的性能造成了(几乎不明显的)影响。

那么您对核心数据有何建议？您会建议采用不同的方法来处理核心数据吗？

我正在考虑混合缓存+核心数据，在其中持久存储我实际上会多次使用的信息(例如用户)，然后使用 RAM 来处理帖子等内容，或者只是创建没有 NSManagedContext 的帖子。 .欢迎输入!

Answer 1

Core Data forces objects to the disk that I do not want forced to the disk.

它不会做这样的事情。如果您不想将您的 Post 对象保存到持久存储中，请不要将它们放在 Core Data 中，也不要将它们设为托管对象。即使 Post 对象不由 Core Data 管理，您的 User 对象也可以具有 posts 属性。托管对象可以具有任何类型的属性，而不仅仅是其他托管对象。

Having to constantly worry about concurrency of contexts, objects and the likes.

无论您如何对数据建模，并发都是复杂的。这是一个根本上复杂的问题。您在 Core Data 中遇到它是因为您正在使用 Core Data。如果您使用其他东西，您将在那里处理它。

Decreased performance.

“产品”菜单 -->“分析”并运行 Instruments 以找出原因。没有理由发生这种情况，并且您有工具可以发现实际发生的情况。