ios - 使用 CoreData 在两个队列之间传递对象引用的最佳实践是什么？

Question

我正面临一个应用程序架构设计的决定。

应用程序使用 CoreData 来保存用户信息，相同的信息也存储在可通过 REST 接口(interface)访问的远程服务器上。当应用程序启动时，我提供来自 CoreData 的缓存信息以供显示，同时我从服务器获取更新。获取的信息也会自动保存。

所有这些任务都在后台队列中执行，以免阻塞主线程。我强烈推荐我的persistenContainer我的 NSManagedObject 称为 User .

@property (nonatomic, retain, readwrite) User *fetchedLoggedInUser;

正如我所说，用户被填充通过执行获取请求

[_coreDataManager.persistentContainer performBackgroundTask:^(NSManagedObjectContext * _Nonnull context) {
        (...)
        NSArray <User*>*fetchedUsers = [context executeFetchRequest:fetchLocalUserRequest error:&fetchError];
        (...)
        self.fetchedLoggedInUser = fetchedUsers.firstObject;
        //load updates from server
        Api.update(){
            //update the self.fetchedLoggedInUser properties with data from the server
            (...)
            //persist the updated data
            if (context.hasChanges) {

            context.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy;
            NSError *saveError = nil;

            BOOL saveSucceeded = [context save:&saveError];

            if (saveSucceeded) {

                //notify the App about the updates
                //**here is the problem**
            }
        };
}];

所以显而易见的是，在执行了 backgroundTask 之后，我的 self.fetchedLoggedInUser不再在内存中，因为它对 performBackgroundTask() 提供的 NSManagedObjectContext 的弱引用我的 PersistentContainer。
因此，如果我尝试从另一个模型访问信息，则值为 nil .
每次我想访问它的值时，将获取的 ManagedObject 保存在内存中而不必再次获取它的最佳实践是什么？

一)在 Documentation , Apple 建议使用 objectID ManagedObject，在队列之间传递对象
在队列之间传递引用

NSManagedObject instances are not intended to be passed between queues. Doing so can result in corruption of the data and termination of the application. When it is necessary to hand off a managed object reference from one queue to another, it must be done through NSManagedObjectID instances.

You retrieve the managed object ID of a managed object by calling the objectID method on the NSManagedObject instance.

这种情况下完美的工作代码是替换 if(saveSucceeded)检查此代码:

if (saveSucceeded) {

   dispatch_async(dispatch_get_main_queue(), ^{
      NSError *error = nil;
      self.fetchedLoggedInUser = [self.coreDataManager.persistentContainer.viewContext existingObjectWithID:_fetchedLoggedInUser.objectID error:&error];
      (...)
      //notify the App about the updates
   });
}

但我认为这可能不是这里最好的解决方案，因为这需要访问 mainQueue 上的 mainContext(在本例中为 persistentContainer 的 viewContext )。这可能与我在这里尝试做的事情相矛盾(在后台执行，以实现最佳性能)。

我的其他选择(嗯，这些，我想出的)将是

B) 将用户信息存储在 Singleton 中，并在每次从 CoreData 获取信息并保存到 CoreData 时对其进行更新。在这种情况下，我不需要担心保持 NSManagedObject 上下文处于事件状态。我可以对我的 persistentContainer 的 performBackgroundTask 提供的私有(private)背景上下文执行任何更新。每当我需要保留新的/编辑的用户信息时，我都可以从数据库中重新获取 NSManagedObject，设置属性，保存我的上下文，然后更新单例。我不知道这是否优雅。

C) 编辑我的 self.fetchedLoggedInUser 的 getter 方法包含一个获取请求并获取所需的信息(这可能是最糟糕的，因为访问数据库时的开销)，我什至不确定这是否会起作用。

我希望这些解决方案之一实际上是最佳实践，但我想听听您的建议，为什么/如何或为什么/如何不处理信息的传递。

TL:博士； 当加载和存储新信息主要是从 backgroundQueues 完成时，保持用户信息在整个应用程序中可用的最佳做法是什么？

PS:我不想每次需要在我的一个 ViewController 中访问它时都获取信息，我想将数据存储在一个中心结上，以便可以从每个 ViewController 轻松访问它。目前 self.fetchedLoggedInUser是在整个应用程序中使用的单例的属性。我发现这样可以节省很多冗余代码，使用 Singleton 可以更清晰地加载和存储信息并减少对数据库的访问次数。如果这被认为是不好的做法，我很乐意与您讨论。

Answer 1

使用 NSFetchedResultsController - 它们非常高效，您甚至可以将它们用于一个对象。 FetchedResultsController 执行一次获取，然后监视核心数据的更改。当它改变时，你有一个回调它已经改变。它也适用于任何核心数据设置。只要更改传播到主上下文(使用 newBackgroundContext 或 performBackgroundTask 或子上下文或其他)，fetchedResultsController 就会更新。因此，您可以在不更改监控代码的情况下自由更改核心数据堆栈。

一般来说，我不喜欢保留指向 ManagedObjects 的指针。如果从数据库中删除该条目，则当您尝试访问它时 managedObject 将崩溃。 fetchedResultsController 总是可以安全读取 fetchedObjects因为它会为您跟踪删除。

明明附上NSFetchedResultsController到 viewContext 并且只从主线程中读取它。