一个或多个UIManagedDocuments

Question

好吧，假设我正在制作一个观鸟应用程序。

有一个“官方”的鸟类数据库。它被存储在一个UIManagedDocument中。它用于用所有的鸟填充UITableView，并用图片和数据显示每只鸟的一些详细视图。这个数据库将在未来升级，增加更多的鸟类物种。

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

从日记的详细视图，你可以转到“官方”鸟的详细视图。从该视图中，您可以转到一个列表，其中包含用户日记中该鸟的所有注册表。

问题是:我应该为用户的每个条目使用一个UIManagedDocument吗？这是如何在带有缩略图的UITableView上工作的？

Answer 1

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

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

你不会为日记条目使用单独的文档，就像你不会为写作的每一段使用单独的Word文档一样。

因为你的应用程序听起来更像是苹果所谓的“鞋盒应用程序”，在这个应用程序中，一个用户只有一堆数据，他们可以在其中添加和减去数据，因此实际上没有必要使用文档架构。但是，这样说来，UIManagedDocument为您提供了一个免费的堆栈，因此可能会很有用。

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

1. 为您的官方鸟类提供一个只读数据库。这个数据库在第一次启动时下载&每当它需要更新的时候。你不应该试图把它放在你的包里，因为它将是相当大的。任何时候都不会对其进行备份。
2. 一个可读写的数据库，保存您的日记条目。该数据库被备份到iCloud，并且在使用GUID而不是CoreData关系耦合两个数据库的鸟牌database.
3. Loosely的升级过程中不会被触及。

​

​

例如，绿头鸭的GUID可能是DUCK1234。将该GUID作为属性(例如birdGUID )写入日记条目。要找到野鸭的所有日记条目，在日记数据库上运行"birdGUID == 'DUCK1234'“查询，就会得到找到的所有时间。

这样做的原因是，您可以升级官方鸟牌数据库，而不必担心损害用户数据。假设你购买了一个更好/更便宜的数据库，或者另一个有鸟叫的数据库，你可以调整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 -模型控制器。处理文件包装机制，并提供免费堆栈。不是必需的。可以使多文档应用程序更容易(或not).
• NSManagedObjectModel模型，核心数据模型的模式。
• NSPersistentStore -模型，表示磁盘上的单个SQLite数据库。
• NSPersistentStoreCoordinator -任意数量的NSPersistentStore
• NSManagedObjectContext模型工作区的控制器，就像一张便签纸。使用并保存或使用并放弃。

在这个阶段，不要与UIManagedDocument捆绑在一起。它是一个文件系统的控制器，上面有一个CoreData堆栈。它不会执行您想要的开箱即用功能。

担心真正的问题，即如何加载这两个数据库，并使用它们的数据来驱动您的UI。

如果以后真的很重要，你可以移动一个基于UIManagedDocument的架构。如果这是我的应用，我就不会费心了。

Answer 2

我甚至不确定我是否会为你的应用程序提案使用一个UIManagedDocument，更不用说为每个用户输入一个了。如果您的应用程序设计的目的是拥有多个基于区域的鸟类“书籍”(作为示例)，那么每个“书籍”的UIManagedDocument将是有意义的，但在我看来，您正在制作一个关于鸟类的单一数据库，该数据库将随着时间的推移而建立，外加一个列出用户全部内容的“日记”(但仍然是主要鸟类数据库的一部分)。

你的应用程序听起来像是基于核心数据的应用程序的候选者。您的模型设计将包含鸟类的记录，外加一个表示“日记”的记录，该“日记”相互关联地交叉引用鸟类记录的“现场用户条目”。即使您有多个“日记”，UIManagedDocuments似乎也有些夸张，如果坚持使用“简单的”核心数据实现，效果会更好。

为简单起见，采用NSFetchedResultsController来管理核心数据和UITableView之间的交互。

在我看来，合并多个UIManagedDocuments会使你的设计变得相当复杂。

Answer 3

如果你使用UIManagedDocument，看看我的github repo https://github.com/dtrotzjr/APManagedDocument --它可能有用，也可能没用。;-)