Ios 一个或多个UIManagedDocuments

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

有一个“官方”鸟类数据库。它存储在一个

UIManagedDocument

中。它用于填充所有鸟类的

UITableView

，并使用图片和数据为每个鸟类创建一个小细节视图。该数据库将在未来进行升级，增加鸟类种类

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

UITableView

和详细视图

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

---

问题是：我应该为每个用户条目使用一个

UIManagedDocument

？对于带有缩略图的

UITableView

，这是如何工作的？

我甚至不确定我是否会使用一个

UIManagedDocument

，更不用说每个用户条目都使用一个。如果你的应用程序设计的目的是基于区域（例如）有多个鸟类“书籍”，那么每个“书籍”都有一个

UIManagedDocument

是有意义的，但在我看来，你是在建立一个鸟类数据库，随着时间的推移，再加上一个列出用户实体的“日记”（但仍然是主要鸟类数据库的一部分）

你的应用程序听起来像是一个直接的基于核心数据的应用程序的候选。你的模型设计将有鸟类记录，再加上一个表示“日记”的记录，该记录与鸟类记录的“现场用户条目”相对交叉引用。即使你有多个“日记”，

UIManagedDocuments

似乎有些过分，如果坚持“简单”的核心数据实现，可能会更好

为了简单起见，请使用

NSFetchedResultsController

管理核心数据和

UITableView

之间的交互

---

在我看来，合并多个

UIManagedDocuments

会使您的设计变得相当复杂。

A

UIDocument

是物理文件包装器的管理类。

UIManagedDocument

是提供核心数据堆栈的子类

A不仅仅是文件夹或文件的抽象。对于

UIManagedDocument

，该文件夹包含CoreData堆栈连接到的SQLite数据库

你不会对日记条目使用单独的文档，就像你不会对每一段文字使用单独的Word文档一样

由于你的应用程序听起来更像苹果公司所说的“鞋盒应用程序”，其中一个用户有一堆他们添加和删除的数据，因此没有实际需要使用文档体系结构。然而，在说这个

UIManagedDocument

时，它为你提供了一个免费的堆栈，因此可能会被证明是有用的

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

您的官方鸟类的只读数据库。此数据库在首次发布时下载&只要需要更新。您不应该尝试将其放入捆绑包中，因为它将非常大。它在任何时候都不会备份

一个读写数据库，保存您的日记条目。该数据库备份到iCloud，在Bird数据库的升级过程中不会涉及

通过使用guid而不是CoreData关系松散地耦合这两个数据库

e、 g绿头鸭的GUID可能是

DUCK1234

。将该GUID作为一个属性（例如birdGUID）写入日记条目中。要查找绿头鸭的所有日记条目，请在日记数据库中运行一个查询“birdGUID=='DUCK1234'”，您将获得所有发现它的时间

这样做的原因是，您可以升级官方的Bird数据库，而不必担心会损害用户数据。例如，您购买了更好/更便宜的数据库，或者购买了另一个具有Bird调用的数据库，您可以调整模式以应对此问题

编辑

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

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;

我不打算详细解释这一点，因为有很多，但要注意在您的Bird数据库上设置

nsreadonlypersistentstore选项

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

总而言之，堆栈是从下到上的


UIManagedDocument
-模型控制器。处理文件包装器
力学和提供免费堆栈。不是必需的。可能使多文档应用程序更容易（或不容易）
NSManagedObjectModel
-Model，核心数据的模式
模型
NSPersistentStore
-Model，表示数据库上的单个SQLite数据库
磁盘
NSPersistentStoreCoordinator
-任何数量的
NSPersistentStore的控制器
NSManagedObjectContext
-模型工作区，
就像一张便笺。使用并保存或使用并丢弃

在这个阶段，不要被
UIManagedDocument
束缚。它是一个用于文件系统的控制器，上面有一个CoreData堆栈。它不做你想做的事情

真正的问题是如何加载数据库并使用它们的数据来驱动UI

如果以后它真的很重要，您可以移动基于UIManagedDocument的体系结构。如果这是我的应用程序，我就不会麻烦了。
如果您使用
UIManagedDocument
查看我的github repo-它可能有用，也可能没有。
好的，我在一份UIManagedDocument中思考，因为只需几个li就可以轻松删除日记条目及其所有资产