核心数据 - 从NSManagedObjectContext调用的共享代码peformBlock：

我在我的NSManagedObjectContexts上使用performBlock，以便我的更改发生在给定上下文的右侧队列中。我的问题是 - 如果我在performBlock之内进行了很多更改和调用方法 - 是否有一种简单的方法可以确保我使用正确的上下文中的对象。核心数据 - 从NSManagedObjectContext调用的共享代码peformBlock：

实施例：

我有一个activeAccount IVAR（在主队列中创建），其用于在应用程序的当前帐户NSMangedObject。我有一些实例方法使用activeAccount对象执行某些任务 - 获取数据，设置数据。所以我的问题是，如果我在背景NSManagedObjectContext上做了些什么，并且我调用了其中一种共享方法 - 是否有一种我可以使用的模式，以便在我知道的这些方法中使用当前的activeAccount iVar或获取新的。此外，如果我需要做一些事情需要NSManagedObjectContext - 我怎么知道哪一个得到/使用。

我知道使用哪个NSManagedObjectContext的方法是我有一个方法，检查它是否在当前线程上运行 - 然后知道返回主线程的上下文或后台线程的上下文。此外，如果我在后台线程上，我是否允许读取位于主线程上的activeAccount的对象ID，以便我可以在后台线程上获取它的副本？提前致谢。

来源

2012-06-25 Brian

Brian，

线程限制可能是一个棘手的命题来维护。您需要维护的关键是在适当的MOC中使用对象。由于每个托管对象都保持与其主机MOC及其对象ID的链接，因此确实很容易。例如：

NSManagedObjectContext *newMOC = NSManagedObjectContext.new; 

newMOC.persistentStoreCoordinator = oldActiveAccount.managedObjectContext.persistentStoreCoordinator; 

ActiveAccount *newActiveAccount = [newMOC objectWithID: oldActiveAccount.objectID];

现在，每当你从newActiveAccount访问实例在newMOC被创建并，因此，线仅限于该MOC。 objectID s是持久的。 -persistentStoreCoordinator很少，如果有的话，在mainMOC更改。因此，上述代码被适当限制。如果源MOC是瞬态的，则上述技术存在问题。因此，我无法保证上述代码适用于两个背景MOC。

安德鲁

来源

2012-06-25 15:41:44 adonoho

我得先问清楚，你为什么有同时使用这么多的背景？

我使用一个用于后台操作，一个用于主线程。如果我需要为可丢弃的更改创建另一个，那么我将创建它并将其传递，所以现在我的self.managedObjectContext指向草稿上下文。我绝不会让我的托管对象生活在可以访问大量上下文的范围内。

，如果你正在编写iOS或OSX这是不完全清楚，但与iOS例如：

如果我需要一个新的视图控制器推到导航堆栈我将初始化我的目的地视图控制器的managedObjectContext伊娃作为以及任何NSManagedObject子类实例。因为在-prepareForSegue中：我知道是创建草稿上下文还是传递当前草稿，我也知道是否需要通过新创建的上下文中的ID引用它们来初始化这些托管对象实例，或者我可以通过他们。

现在在我的视图控制器中，我可以理所当然地认为我的托管对象总是与自己绑定在一起。managedObjectContext。

来源

2012-06-26 09:39:57 svena

我正在为iOS开发。我真的只有两个MOC，一个用于主线程，另一个用于后台运行。我想我的问题是我有代码，我试图重用，所以我已经放入方法。但我不想说X方法只能在这个ManagedObjectContext中运行。在一个案例中，我正在创建一个新的账户关系。包含它的对象有一个账户iVar。所以我试图决定是否可以加入到iVar中，或者是否需要为后台MOC创建另一个帐户对象。也许我需要将每种方法限制在给定的MOC上。 – Brian

核心数据 - 从NSManagedObjectContext调用的共享代码peformBlock：

回答

相关问题