使用 MagicalRecord 3 的 CoreData 内存设置
CoreData in-memory setup with MagicalRecord 3
您好，我正在使用 CoreData + MagicalRecord 3 来管理我的应用程序中的数据。在那之前一切正常，但后来我意识到在生产中我的应用程序像地狱一样冻结！
所以我开始调查了解这样一个事实，即不要卡住 UI，最好有一个主上下文和一个后台上下文，并将内容保存在后台等...
尽管如此，由于我的设置，我不得不质疑。我使用 CoreData 内存存储系统（为了获得最佳性能）并且我不关心将数据存储在我的应用程序的磁盘上，我对易失性模型很好，当应用程序被杀死或在后台时会被破坏时间过长。我只想能够从任何视图控制器中找到我的数据，而不需要耦合。
所以我有几个问题：
1) 如果我使用 1 个唯一的上下文，如果我从不将它保存到内存存储中会发生什么？例如，如果我 MR_createEntity 然后我从上下文中检索这个实体并更新它，它是在所有地方更新还是我必须保存它以便它可以更新？换句话说，是为了在内存中保存您不想永远保存数据的兴趣吗？
2) 如果我使用 1 个我声明为背景的唯一上下文，如果我在数据保存完成之前显示我的屏幕，屏幕将无法找到并显示我的数据，对吗？除非我正确使用 NSFetchResultController ?
1) 出于多种原因，您甚至希望使用内存存储来保存数据。首先，以便在您可能改变主意并持久化数据的情况下可以正确使用核心数据。其次，您可能希望访问和处理不同 threads/queues 上的一些数据。在这种情况下，您将不得不使用 threads/queues 的 Core Data 数据安全机制。 store 是 Core Data 跨线程同步数据的最低级别（旧方法）。如果您使用嵌套上下文来同步数据（新方式），这可能就不那么重要了。但即使使用嵌套上下文，您也需要调用 save 才能使您的更改跨上下文合并。当您保存到 nil 存储时，Core Data 并不喜欢它。
2) 您可以创建并使用自己的上下文来显示数据。 NSFetchedResultsController 在监听正确的通知和确保您首先获得您要求的数据的非常具体的更新方面做了大量的工作。 NSFRC 并不总是必要的，但肯定是最简单的开始方式。
您好，我正在使用 CoreData + MagicalRecord 3 来管理我的应用程序中的数据。在那之前一切正常，但后来我意识到在生产中我的应用程序像地狱一样冻结！ 所以我开始调查了解这样一个事实，即不要卡住 UI，最好有一个主上下文和一个后台上下文，并将内容保存在后台等...
尽管如此，由于我的设置，我不得不质疑。我使用 CoreData 内存存储系统（为了获得最佳性能）并且我不关心将数据存储在我的应用程序的磁盘上，我对易失性模型很好，当应用程序被杀死或在后台时会被破坏时间过长。我只想能够从任何视图控制器中找到我的数据，而不需要耦合。
所以我有几个问题： 1) 如果我使用 1 个唯一的上下文，如果我从不将它保存到内存存储中会发生什么？例如，如果我 MR_createEntity 然后我从上下文中检索这个实体并更新它，它是在所有地方更新还是我必须保存它以便它可以更新？换句话说，是为了在内存中保存您不想永远保存数据的兴趣吗？
2) 如果我使用 1 个我声明为背景的唯一上下文，如果我在数据保存完成之前显示我的屏幕，屏幕将无法找到并显示我的数据，对吗？除非我正确使用 NSFetchResultController ?
1) 出于多种原因，您甚至希望使用内存存储来保存数据。首先，以便在您可能改变主意并持久化数据的情况下可以正确使用核心数据。其次，您可能希望访问和处理不同 threads/queues 上的一些数据。在这种情况下，您将不得不使用 threads/queues 的 Core Data 数据安全机制。 store 是 Core Data 跨线程同步数据的最低级别（旧方法）。如果您使用嵌套上下文来同步数据（新方式），这可能就不那么重要了。但即使使用嵌套上下文，您也需要调用 save 才能使您的更改跨上下文合并。当您保存到 nil 存储时，Core Data 并不喜欢它。
2) 您可以创建并使用自己的上下文来显示数据。 NSFetchedResultsController 在监听正确的通知和确保您首先获得您要求的数据的非常具体的更新方面做了大量的工作。 NSFRC 并不总是必要的，但肯定是最简单的开始方式。