一个或多个UIManagedDocuments

Question

好的，我想说我正在制作一个观鸟应用程序。

有一个“官方”鸟类数据库。哪个存储在一个UIManagedDocument中。它用于填充所有鸟类的UITableView和每个图片和数据的详细视图。该数据库将来会升级为更多鸟类。

然后，用户可以去乡下拍摄鸟类照片。他将它们添加到应用程序的另一部分，称为“日记”，当他识别出这只鸟时，他将它与一只“官方”鸟链接起来。应使用iCloud备份此信息（所有用户收集的数据）。它还用于填充日记的UITableView和详细视图。

从日记的详细视图中，您可以查看“官方”鸟的详细视图。从该视图中，您可以在用户日记中找到包含该鸟的所有寄存器的列表。

问题是：我应该为每个用户的条目使用一个UIManagedDocument吗？如何使用缩略图UITableView？

Answer 1

UIDocument是物理文件包装器的管理类。 UIManagedDocument是提供CoreData堆栈的子类。

File Wrapper只不过是文件夹或文件的抽象。对于UIManagedDocument，该文件夹包含CoreData堆栈连接的SQLite数据库。

您不会将个别文档用于日记条目，而不是将每个Word文档用于每个写作段落。

由于您的应用听起来更像Apple称之为“Shoebox应用”，其中一个用户只有一堆数据，他们添加到其中并从中减去，并不需要使用文档架构。但是，在说这个UIManagedDocument为你提供一个免费的堆栈，所以可能有用。

如果是我构建这个应用程序，我可能采取这种方法。

1. 您的官方鸟类的只读数据库。该数据库是在首次发布时下载的。无论何时需要更新。你不应该试图把它放在你的捆绑中，因为它会非常大。它不会在任何时候备份。

2. 包含日记条目的读写数据库。此数据库支持iCloud，并且不会触及Bird数据库的升级。

3. 使用GUID而不是CoreData关系将两个数据库松散耦合。



例如野鸭的GUID可能是DUCK1234。在您的日记条目中将该GUID写为属性（例如birdGUID）。要查找野鸭的所有日记条目，请在您的日记数据库上运行“birdGUID =='DUCK1234'”查询，并且您一直看到一个。

这样做的原因是您可以升级官方的Bird数据库，而无需担心损害用户数据。假设你购买了一个更好/更便宜的数据库或一个有鸟叫的不同数据库，你可以调整Schema来应对。

修改

一种方法（一种简单方法）是使用两个NSPersistentStores

构建堆栈

NSPersistentStoreCoordinator *myPersistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:[NSManagedObjectModel mergedModelFromBundles:nil]];

NSDictionary *readonly_options = @{NSReadOnlyPersistentStoreOption:@YES};

[myPersistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:officialBirdStoreURL options:readonly_options error:&error];

NSDictionary *readwrite_opts = @{NSMigratePersistentStoresAutomaticallyOption:@YES,
  NSInferMappingModelAutomaticallyOption:@YES};

[myPersistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:diaryStoreURL options:readwrite_opts error:&error];

NSManagedObjectContext *workingContext = [[NSManagedObjectContext alloc] initWithConcurrencyType: NSMainQueueConcurrencyType];

workingContext.persistentStoreCoordinator = myPersistentStoreCoordinator;

我不会完全解释这个有很多excellent Core Data tutorials，但请注意在你的鸟类数据库上设置NSReadOnlyPersistentStoreOption。

这不涉及使用UIManagedDocument，因为您没有对堆栈进行足够的控制。

总结一下，堆栈从下到上。

• UIManagedDocument - 模型控制器。处理文件包装 机制并提供免费堆栈。不需要。可以使多文档应用程序更容易（或不）。
• NSManagedObjectModel - 模型，核心数据的架构 模型。
• NSPersistentStore - Model，表示单个SQLite数据库 磁盘。
• NSPersistentStoreCoordinator - 任意数量NSPersistentStore
的控制器
• NSManagedObjectContext - 模型工作区， 就像一张便条纸。使用和保存或使用和丢弃。

在此阶段不要与UIManagedDocument捆绑在一起。它是文件系统的控制器，顶部有一个CoreData堆栈。它没有做你想做的开箱即用。

担心真正的问题是如何加载数据库并使用他们的数据来驱动你的UI。

如果以后真的很重要，您可以移动基于UIManagedDocument的架构。如果这是我的应用程序，我不会打扰。

Answer 2

我甚至不确定我会为您的应用提案使用一个UIManagedDocument，更不用说每个用户条目一个。如果您的应用程序设计旨在根据区域（例如）有多个鸟类“书籍”，那么UIManagedDocument每个“书”都有意义，但听起来像是在制作单个数据库随着时间推移将建立的鸟类，以及列出用户入口的“日记”（但仍然是主要鸟类数据库的一部分）。

您的应用听起来像是基于Core Data的直接应用的候选者。您的模型设计将包含鸟类记录，以及代表“日记”的记录，该记录关联地交叉引用鸟类记录的“现场用户条目”。即使您有多个“日记”，UIManagedDocuments似乎也有些过分，并且可以更好地服务于坚持“简单”的核心数据实施。

为了简单起见，请使用NSFetchedResultsController来管理Core Data与您的UITableView之间的互动。

在我看来，合并多个UIManagedDocuments会使您的设计大大复杂化。

Answer 3

如果你选择UIManagedDocument，请参阅我的github repo https://github.com/dtrotzjr/APManagedDocument - 这可能有用，但可能没有。 ; - ）