0

我最初认为我的问题的答案是简单的“是”，但从那以后我所做的一些阅读让我再次看到了这个问题。

我的意图是使用模块化代码，这让我可以从多个代码部分中进行选择，以向应用程序添加各种功能。例如，我可能有一个允许安全浏览的浏览器组件、一个用于进行用户调查的调查组件，以及一个作为应用程序主要用途的“核心”组件——无论是显示菜单还是显示地图的一个位置。

我希望每个独立的模块都有自己的 CoreData 堆栈。除了由应用程序本身介导的任何事情（使用委托模型完成的与应用程序的通信）之外，它们不会以任何方式相互交谈或相互干扰。浏览器的书签列表和列入白名单的站点与调查的调查数据列表是分开的，这也与应用程序的“核心”所做的任何事情完全分开。如果他们需要相互交谈，他们可以通过委托调用来实现，这将包括告诉应用程序“我需要一个浏览器来显示 X 页面”、“使用这个 id 显示调查”，或者最后是“我是完成，返回主应用程序”。

让我开始走这条路的是意识到没有办法确定给定的 NSManagedObjectContextDidSaveNotification 是否属于给定的核心数据堆栈。而且，据推测，在 mergeChangesFromContextDidSaveNotification: 方法中向 MOC 提供来自不同核心数据堆栈的通知将是一个坏主意。（我也担心当你尝试将 MOC 自己的通知反馈给它时会发生什么，但这是我可以很容易地尝试的东西）

4

2 回答 2

5

您可以（并且这在 NSManagedObjectContext 文档中明确推荐）注册来自特定上下文的更改：

[[NSNotificationCenter defaultCenter] addObserver:self
                           selector:@selector(<#Selector name#>)
                               name:NSManagedObjectContextDidSaveNotification
                             object:<#A managed object context#>];

当你收到这样的通知时，通知对象就是托管对象上下文。因此，可以创建独立的组件，其中每个组件都使用自己的核心数据堆栈。

于 2013-04-12T18:15:20.147 回答
1

正如 Martin R 所指出的，您可以注册来自特定上下文的通知。如果您正在侦听来自多个上下文的通知，则还可以询问通知是哪个上下文发布了它并根据该上下文继续。使用NSManagedObjectContextDidSaveNotification，查看[notification object]以找出发布它的上下文。

除非存在某种与安全相关的问题，否则将对象保存在完全不同的堆栈中并具有单独的持久存储似乎有些过分。就像也许，出于某种原因，一个数据集合永远不允许靠近其他数据集合，这一点非常重要。如上所述，该应用程序似乎没有任何令人信服的理由来说明额外的复杂性。

您可能会发现最好使用一个堆栈和一个持久存储，但具有多种配置。每个配置都将包含来自数据模型的特定实体。您将有一个持久存储和一个NSManagedObjectModel实例，但有多个NSPersistentStoreCoordinator实例。调用时指明您想要的配置addPersistentStoreWithType:configuration:URL:options:error:。

于 2013-04-12T18:37:00.933 回答