Iphone 两种不同ManagedObjectContext中的CoreData关系

警告：这是我的第一个IPhone应用程序，我对Objective C还不熟悉，因此我的问题可能非常基本

实际上我有一个概念上的问题：

我的NSObjects项目与WorkTime Project>WorkTime之间存在一对多关系。WorkTime具有startDate、endDate等属性，以及名为project的项目与项目对象的关系

在显示工作时间列表的UITableViewController子类上，我使用FetchedResultsController获取CoreData模型。当我创建一个新的工作时间时，我使用第二个上下文并将其与默认上下文合并一次，一旦用户在深入视图上单击save（保存），就像Apple文档中的CoreDataBooks示例一样。这很有效

当我设置关系时，问题就开始了。由于项目处于“默认”上下文中，我无法在工作时将任何项目对象分配给项目键，因为它们处于两个不同的上下文中

那么，我是否应该将所有项目复制到“保存”上下文中？或者我应该对每件事都使用一个上下文吗

当我只使用一个上下文时出现的一个问题是，当用户单击addbutton insertNewObjectForEntityForName时，显示工作时间的tableview就会实现。因此，该列表在显示modalviewcontroller中的新视图控制器addWorkTimeDetail之前会增长。如果用户在细节视图中单击cancel并决定不保存工作时间，我将不得不从上下文中删除新创建的实体。我不认为这听起来是个好办法

建议将非常感谢

更新

我仍然有一些问题：

当从RootViewController创建AddWorkTimeViewController时，我将创建一个新的NSObject WorkTime。当用户单击“取消”时，我将删除新创建的工作时间并返回到RootViewController。FetchedResultsController实现了tableView，我看到了一个简短的动画，因为对象已被删除。那看起来不太好

我知道只有在用户单击save（保存）并单击cancel（取消）不执行任何操作时才创建对象会更好，但我需要该对象以便用值填充深入视图。深入查看视图与NSManagedObject一起使用。我认为有两种可能的解决方法：

1使用与WorkTime NSManagedObject相同的属性从NSObject中创建临时对象TempWorkTime子类。我将在AddWorkTimeViewController中创建TempWorkTime，并将其用于深入视图。当然，我必须对它们进行子类化，以接受NSObject而不是NSManagedObject。我猜类型转换不起作用。当用户单击save时，我将创建一个WorkTime NSManagedObject，并将TempWorkTime中的值传递给它

2是否可以欺骗FetchedResultsController，使其在tableView不可见时不更新自身？在这种情况下，它在返回视图之前不会响应上下文中的更改，因此不会执行删除动画

有什么建议吗

第二次更新-可能对尝试做同样事情的人有用

---

我发现这个链接非常有用：

这很好地解释了为什么有时使用两种上下文是个好主意。我在使用问题的更新部分解释的上下文时遇到了一些问题

---

现在我使用了两个上下文，它工作得非常完美，即使是在关系中。重要的是在创建关系时使用第二个上下文的NSManagedObjects。当我开始使用这种方法时，这是我的错误。

我不明白为什么要使用两种不同的上下文

方法是将tableView的上下文传递给addWorkTimeDetail，并将任何新的工作时间添加到该上下文中。如果用户取消，即不创建新对象，则返回时列表中不会有任何新内容。如果用户在传递的上下文中创建了新的工作时间，则返回时它将显示在列表中

---

在您的示例中，只使用一个上下文，并将其传递给子视图

我发现这个链接非常有用：

这很好地解释了为什么有时使用两种上下文是个好主意。我在使用问题的更新部分解释的上下文时遇到了一些问题

---

现在我使用了两个上下文，它工作得非常完美，即使是在关系中。重要的是在创建关系时使用第二个上下文的NSManagedObjects。当我开始使用这种方法时，这是我的错误。

我认为从设计角度来看，如果只有一个类，RootViewController可以处理上下文和coredata内容，而子视图可以将用户选择通知RootViewController，那会更好。听起来我错了！你建议的方式听起来容易多了。但是如果我得了hie怎么办

---

少有的子视图，它们都传递自己的上下文？听起来他们的结合太紧密了。这就是我考虑将上下文作业集中到RootViewController的原因。通常情况下，您实际上将上下文停在app委托中，这样它就可以被普遍接受。或者，您可以使用注入模型，它只是根据需要显式地将上下文从视图控制器传递到视图控制器。好的，注入模型是推荐的，但我想它们都同样有效@Sara，是的，如果你有层次结构A->B->C A传递到B，B传递到C。对不起，我在错误的位置添加了我的更新/编辑，请忽略！