在 iOS 上使用 Core Data 处理类似于多个文档的内容答案

【问题标题】：Using CoreData on iOS to handle something that is akin multiple Documents在 iOS 上使用 Core Data 处理类似于多个文档的内容
【发布时间】：2011-11-20 04:25:32
【问题描述】：

我一直在尝试确定一种优雅的方式来处理在 iOS 上使用 CoreData 实现设计，类似于处理多个文档。

作为背景，我有一个培训应用程序，我想在其中支持培训课程的应用程序内购买。这些可能是包含.sqlite 和一些支持媒体文件的文件包，下载后这些文件最终将位于App Library 文件夹中的CourseName 子文件夹中。

我希望能够支持在我的应用的根级别的表中列出所有Coursenames，并根据用户选择的一个在它们之间切换。

我的直觉是我可以将 Store 切换到适当的 sqlite。

    NSString *sqliteFileForCourseName = [self sqliteFileForCourseName];
    storeURL = [[self applicationLibraryDirectory] URLByAppendingPathComponent:sqliteFileForCourseName];
    if(!__persistentStoreCoordinator)
        __persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:[self managedObjectModel]];
    if (![__persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeURL options:options error:&error])
    // handle error

我认为这将是管理[persistentStoreCoordinator persistentStores] 中的项目的问题。

我不确定这是否是处理该功能的正确级别（多个持久存储），或者是否可以在 NSManagedObjectContext 级别完成。

如果从库文件夹中加载课程时，我可以忍受它们是只读的，如果它简化了拥有一个可写存储和多个只读存储的事情（也许NSInMemoryStoreType？）

【问题讨论】：

标签： iphone ios sqlite core-data

【解决方案1】：

如果您所做的只是处理文档列表，那么NSArray 和NSUserDefaults 可能是您最好的选择。它在技术上不那么令人印象深刻，但最简单的解决方案通常是最简单的。

对于每个文档，除非您确实有大量数据要读取，否则我不会使用 sqlite 数据库。我会去一个带有 .json 文件的存档，该文件提供该文档的信息，即

index.json

{
    "name":"Document 1",
    "author":"Bob Smith"
    "pages":[
        { "title":"Title", "path":"title.html" },
        { "title":"Contents", "path":"contents.html" },
        { "title":"1", "path":"contents/1.html" }
    ]
}

其中每个页面都是一个 html 文件（或您想要的任何格式），并且它的位置在文档的 json 描述中指定。

只需创建一个实现 NSCoding 的 Document 对象 - 从上面的 JSON 创建它并将其存储在您的 NSUserDefaults 中。

然后，在启动时，只需从您从 NSUserDefaults 读取的数组中填充您的 UITableView，使用标题作为 UITableViewCell 中的文本。

但是，使用 sqlite 可能有一个正当的理由 - 您是否计划对这些文档进行任何特别复杂的处理？

【讨论】：

感谢您的回复。我的应用程序已经在使用 CoreData 写入和读取 sqlite。因此，生成这些包含 sqlite 和支持媒体文件的 Bundle 非常简单。我正在尝试找到阻力最小（或编码最少）的路径来在这些 Bundles 中的 sqlite 文件之间切换。
啊，那我的回答也帮不上什么忙！对不起！我不会尝试同时加载所有商店，我不知道它是如何工作的 :( 每次用户选择一个文档时，我都会创建一个新的持久性存储。但是，没有理由为什么该方法你在你的问题中建议是行不通的:)

【解决方案2】：

将这些作为持久存储进行管理似乎完全正确。这就是他们的设计目的。您无法在 MOC 级别上真正控制它。一个逻辑“文档”可以有多个 MOC。例如，在大多数情况下，每个线程都需要一个单独的 MOC。将这些东西分开的正确位置是持久存储。

【讨论】：