使用NSManagedObject子类传输持久性和非持久性数据

et_et 发布于 2019-03-09 ios 最后更新 2019-03-09 14:41 3 浏览

我对如何使用核心数据的NSManagedObject子类来处理持久数据和非持久数据有一些想法。 比方说,你有一个配方应用程序显示你自己的CoreData食谱列表,在这个相同的应用程序,你也可以搜索其他用户食谱。 这些其他用户配方当然是来自API,我们不希望将它们保存到核心数据中。 但是,我们想要的是我们的配方详细信息视图控制器行事相同,无论它是一个永久的配方或一个非持久的配方。 我自然认为我们应该对数据使用相同的对象包装,并让我们的视图控制器对数据的来源视而不见。 问题是NSManagedObject子类不能手动初始化,必须插入到上下文中。这对我们的其他用户食谱并不好。另一方面,对于我们自己的食谱,我们需要将这些对象插入到上下文中。 我有几个解决方案,但我真的很想阅读你们对这个问题的看法。 你会说这是一些实现问题,应该通过将两个数据对象封装到一个对象中来解决吗?例如,通过覆盖所有getter和setter来处理coredata对象和NSDictionary对象? 或者它是一个体系结构问题,你可以通过嵌套NSManagedContext或者使用多个持久存储(一个存储在内存中而另一个是Sqlite)来解决它?

已邀请:

qet

赞同来自:

模型配置 - 内存存储和sqlite支持的存储。 我会认真考虑使用模型配置和两种持久存储类型: 内存和sqlite支持。 但这也意味着您必须为可下载数据创建单独的实体,这样可以使您可以将某些配方保持持久性并且在它们都是配方时具有一些临时性的想法无效。此外,您不能在不同持久性存储中的实体之间建立关系。您将放弃反向关系的好处,并且必须使用获取的属性来模仿它。 总而言之,它是一个可行的选择,有一些缺点。 孤立的托管对象上下文 使用单独的托管对象上下文的最大优点是,您可以对持久数据和临时数据使用相同的配方实体。您必须避免保存临时上下文,并且必须从持久性存储中引入所有更改,或者从具有您保存的数据的其他上下文中进行合并。 这种替代方案的挑战在于,您必须在此独立的上下文之上构建大部分UI以进行读取,但是您所做的所有永久性更改都需要保存到主上下文中,并通过合并到隔离的上下文中进行传播。这可能会引入一些棘手的情况,但我认为这是可行的。

eearum

赞同来自:

实际上,您可以创建NSManagedObject实例,而无需将它们插入上下文中。只需将nil作为托管对象上下文参数传递。做类似的事情:

NSEntityDescription *myRecipeEntity = [NSEntityDescription entityForName:@"MyRecipeEntity" inManagedObjectContext:[self managedObjectContext]];
MyRecipeClass *recipe = [[MyRecipeClass alloc] initWithEntity:myRecipeEntity insertIntoManagedObjectContext:nil]];
现在您有一个不在任何上下文中的配方实例。 如果您以后想要将其添加到上下文中:
[[self managedObjectContext] insertObject:recipe];
如果您不想插入它,只需扔掉即可。

tut

赞同来自:

我可能只是使用一个你永远不会保存的单独上下文,这似乎是最简单的路径。