在这篇文章中，我们将建立一个小型但却全面支持 Core Data 的应用。此应用允许你创建嵌套的列表；每个列表的 item 都可以有子列表，这将允许你创建非常深层次的 items。为了让大家完整的了解发生了什么，我们将通过使用手动创建堆栈的方式来代替 Xcode 中 Core Data 的模板。这个应用的代码放到了GitHub上。
我们将怎么建立？
首先，我们创建一个 PersistentStack 对象，为其提供一个 Core Data 模型和一个文件名，PersistentStack 会返回一个 managed object context。然后，我们将要创建我们的 Core Data 模型。接着，我们将创建一个简单的 table view controller 来显示使用 fetched results controller 取回的 item 根目录，并且通过增加 items，sub-items 的导航，删除 items，增加 undo 支持，来一步一步进行交互。
设置堆栈
我们将为主队列创建一个 managed object context。在比较老的代码中，你可能见到[[NSManagedObjectContext alloc] init]。而目前，你应该用initWithConcurrencyType:初始化，以明确你是使用基于队列的并发模型。
检查错误是非常重要的，因为在开发过程中，这很有可能经常出错。当 Core Data 发现你改变了数据模型时，就会暂停操作。你也可以通过设置选项来告诉 Core Data 在遇到这种情况后怎么做，这在 Martin 关于迁移的文章中彻底的解释了。注意，最后一行增加了一个 undo manager；我们将在稍后用到。在 iOS 中，你需要明确的去增加一个 undo manager，但是在 Mac 中，undo manager 是默认有的。
这段代码建立了一个真正简单的 Core Data 堆栈：一个拥有持久化存储协调器的 managed object context，其拥有一个持久化存储。更复杂的设置都是可能的；最常见的是拥有多个 managed object context（每一个都在单独的队列中）。
创建一个模型
创建模型比较简单，我们只需要增加一个新文件到我们的项目，在 Core Data 选项中选择 Data Model template。这个模型文件将会被编译成后缀名为.momd类型的文件，我们将会在运行时加载这个文件来为持久化存储创建需要用的NSManagedObjectModel，模型的源码是简单的 XML，根据我们的经验，一般来说当你 check 到代码版本管理中时，应该不会有任何 merge 的困难。如果你愿意，你还可以在代码中创建一个 managed object model。
一旦你创建了模型，你就可以增加 Item 实体，这个实体有两个属性：字符串类型的title和 integer 类型的order。然后，增加两个关系：一个叫做parent，表示这个 item 的父 item；另一个叫children，是一个一对多的关系。设置它们为彼此相反的关系，也就是说，你设置 a 的 parent 为 b，那么 b 就会自动有一个 children 为 a。
通常，你甚至可以完全抛开 order 属性，而去使用排序好的的关系。然而，它们并不能很好的和 fetched results controllers（后面会用到）集成在一起工作。我们要么需要重新实现 fetched results controller 的一部分，要么重新实现排序，通常我们都会选择后者。
现在，从菜单中选择Editor > NSManagedObject subclass...，创建一个绑定到实体的 NSManagedObject 的子类，这将会创建两个文件：Item.h和Item.m。在头文件中，会有一个额外的类别，我们需要将其删除（这是遗留原因导致的）。
创建一个 Store 类
对于我们的模型，我们将创建一个根节点作为我们 item 树的开始。我们需要一个地方来创建这个根节点，并且方便以后找到。因此，我们可以通过创建一个简单的存储类来达到这个目的。存储类有一个 managed object context，还有一个rootItem方法。在 app delegate 中，我们将会在程序启动时查找这个 root item，并且传给了 root view controller。作为一种优化，为了查找这个 item 变得更快，你可以将 item 对象的 id 存储到 user defaults 中：
大多数情况下，增加一个 item 都是简单的。然而，我们需要设置 order 属性值比任何其父节点的子节点的值更大。我们将会设置第一个子节点的 order 值 为0，随后每一个子节点都会增加1。我们在Item类中创建一个自定义的方法来实现：
获得子节点数量的方法很简单：
为了支持自动更新我们的 table view，我们需要使用 fetched results controller。Fetched results controller 是一个可以管理取出大量 item 请求的对象，同时对使用 Core Data 的 table view 来说，它也是一个完美的小伙伴，在下一节中我们将会用到：
增加一个支持 Table-View 的 Fetched Results Controller
我们下一步是创建一个 root view controller：一个从NSFetchedResultsController读取数据的 table view。Fetched results controller 管理你的读取请求，如果你为它分配一个 delegate，那么在 managed object context 中发生的任何改变都会通知你。实际上，这意味着如果你实现了 delegate 方法，当数据模型中发生相关变化时，你可以自动更新你的 table view。比如，你在后台线程同步，并且把变化存储到数据库中，那么你的 table view 将会自动更新。
创建 Table View 的 Data Source
在更轻量的 View Controllers这篇文章中，我们演示了怎么从 table view 中分离出 data source。这里，我们将会用同样的方法创建一个 fetched results controller。我们创建一个分离出的FetchedResultsControllerDataSource类，它扮演了 table view 的 data source，通过监听 fetched results controller，自动更新 table view。
我们初始化一个 table view 对象，初始化方法如下：
当我们设置 fetch results controller 时，我们需要设置自己为 delegate，并且执行初始化的 fetch 操作。performFetch:方法经常容易被忘了调用，那么你将得不到结果（并且不会出错）：
因为我们的类实现了UITableViewDataSource协议，我们需要实现相关的方法。在这两个方法中，我们只需要向 fetched results controller 请求需要的信息：
然而，当我们需要创建 cell 的时候，只需要一些简单的步骤：向 fetched results controller 请求正确的对象，从 table view 出列一个cell，然后告诉 delegate (即一个 view controller) 用相应的对象配置这个 cell。作为 view controller，只会关心用模型对象更新cell：
创建 Table View Controller
现在，我们可以创建一个 view controller，使用刚刚创建的类显示 item 列表。在示例程序中，我们创建一个 Storyboard，并且增加一个拥有 table view controller 的 navigation controller。这会自动设置 view controller 作为数据源，而这不是我们想要的效果。因此，在我们的viewDidLoad中，我们做下面的操作:
在初始化 fetched results controller data source 时，table view 的数据源可以被设置。reuse 标识符匹配在 Storyboard 中相对应的对象。现在，我们需要实现 delegate 方法：
当然，除了设置 text 的 label 外，你还可以做更多的事情，但是你应该已经明白了要领。现在我们已经为显示数据准备好了相当多的事情，但是却仍然没有增加数据的方法，这看起来非常空。
增加互动
我们将会增加两种和数据交互的方法。首先，我们需要实现增加 items。然后我们需要实现 fetched results controller 的 delegate 方法去更新 table view，并且增加删除和 undo 支持。
增加 Items
为了增加 items，我们借鉴Clear的交互设计，这是我认为最漂亮的应用之一。我们增加一个 text field 作为 table view 的头，并修改 table view 的 content inset，确保它默认保持隐藏，正如 Joe 在scroll view这篇文章中解释一样。像往常一样，所有的代码都在 github 上，这里是插入 item 相关的代码，在textFieldShouldReturn:
监听改变
下一步是确保 table view 会为新创建的 item 插入一行。有好几种方法可以做到，但是我们将会使用 fetched results controller 的代理方法
fetched results controller 也会在删除、改变和移动时调用一些方法（我们将在稍后实现）。如果你一次有很多改变，你可以多实现两个方法，那么 table view 将会动画地展现所有的改变。对于单个 item 的插入和删除，这并不会有任何不同，但是如果你选择实现同时同步，那么将会变得更漂亮：
使用 Collection View
值得注意的是，fetched results controllers 并非只能用于 table views；你可以将它只用在任何 view 中。因为它们是基于 indexPath 的，所以它们能与 collection views 很好的一起工作。由于 collection view 没有beginUpdates和endUpdates方法，却有一个performBatchUpdates方法，所以我们需要稍加改变。你可以收集你得到的所有更新，然后在controllerDidChangeContent中，用 block 执行所有的更新。Ash Furrow 写了一个关于如何做的例子。
实现你自己的 Fetched Results Controller
你不必使用NSFetchedResultsController。实际上，在很多情况下，为你的程序创建一个类似的类将显得更有意义。你可以做的是注册NSManagedObjectContextObjectsDidChangeNotification。然后你就可以得到一个notification，userInfo字典将会包含改变对象，插入对象，删除对象的列表，然后你可以按你喜欢的方式执行这些操作。
传递 Model 对象
现在我们可以增加并且列出 itmes 了，现在我们需要确定能够创建 sub-lists。在 Storyboard 中，你可以通过拖拽一个 cell 到 view controller 中来创建一个 segue。最好给 segue 指定一个名字，这样，如果一个 view controller 中有多个 segues 的话，我们就可以将其区分开了。
我处理 segues 的模式看起来像这样：首先，你尝试识别出这个 segue，对于每一个 segue，你为它的目标 view controller 单独写一个方法：
子 view controller 需要唯一的东西就是item。通过 item，也可以得到 managed object context。我们从 data source 中得到选中的 item（通过 table view 选中的 item 的 index 值，从 fetched results controller 中取出正确的 item），就这么简单。
很不幸的是，在 app delegate 中，将 managed object context 作为一个属性，然后总是在任何地方访问它，这是模式非常常见。这其实是一个坏主意。如果你想要为你 view controller 中的一部分使用一个不同的 managed object context时，将很难重构，此外，你的代码将变得很难测试。
现在，尝试在 sub-list 中增加一个 item，你很有可能得到一个 crash。这是因为我们现在有两个 fetched results controllers，一个是 topmost view controller，还有一个是root view controller。后者尝试去更新它的 table view，而它的table view是离屏的(offscreen),就这样所有的操作都crash了。解决方案是告诉我们的data source停止监听fetched results controller的代理方法：
一种方法就是在 data source 中设置 fetched results controller 的代理为nil，这样就再也不会收到更新通知了。当我们离开paused状态时，还需要加上去：
这样performFetch就会确保你的 data source 保持最新的。当然，更好的实现方法并不是设置代理为nil，而是记录每一个在 paused 状态下的改变，相应的，在离开 paused 状态后，更新 table view。
删除
为了支持删除，我们需要花费几步操作。首先，我们需要确信我们的 table view 支持删除。第二，我们需要从 core data 中删除对象，并且保证我们的排序是正确的。
为了支持滑动删除，我们需要在 data source 中实现两个方法：
我们需要通知代理（the view controller）删除对象，而不是直接删除。这样，我们不需要将 store object 分配给data source（data source 在整个项目中都必须可重用），并且保持自定义操作的灵活性。view controller 只需在 managed object context 中简单的调用deleteObject:。
然而，还有两个重要的问题需要被解决：我们怎么处理被删除 item 的子 item，怎么强制我们的 order 变化？幸运的是，传播删除是很简单的：在我们的数据模型中，我们可以选择Cascade作为子关系的删除规则。
为了强制我们的 order 变化，我们可以重写prepareForDeletion方法，用更高一级的order更新所有兄弟节点。
现在我们几乎快完成了。我们可以与 table view 的 cell 交互，并且可以删除模型对象。最后一步是实现一旦模型对象被删除后，删除 table view cell 的必要的代码。在 data sources 的方法controller:didChangeObject:...中，我们增加另一个 if 语句：
增加 Undo 支持
Core Data 优点之一就是集成了 undo 支持。我们将为增加晃动撤销功能，第一步就是告诉程序我们可以这么做：
现在，这个功能可以被任何抖动触发，程序将会向 first responder 请求 undo manager，并且执行一次 undo 操作。在上个月的文章中，我们了解了，一个 view controller 也在响应链中（responder chain），这也正是我们将要使用的。在我们的 view controller 中，我们重写来自UIResponder类中的两个方法：
现在，当一个抖动发生时，managed object context 的 undo manager 将会得到一个undo消息，并且撤销最后一次改变。记住，在 iOS 中，managed object context 默认并没有一个 undo manager，（而在 Mac 中，新建的 managed object context 默认是有的），所以我们需要在持久化堆栈中设置：
基本上就是这样了。现在，当你抖动时，你将得到 iOS 默认有两个按钮的提醒框：一个是 undo 按钮，一个 cancel 按钮。Core Data 的一个非常好的特性是将改变自动分组。比如，addItem:parent将会记录作为一个 undo 处理。关于删除，也是一样的。
为了让用户管理 undo 操作更容易一些，我们可以给操作命名，并且将 textFieldShouldReturn: 的第一行修改成这样：
现在，当用户抖动时，除了普通的 "Undo" 标签外，他将得到更多的上下文环境。
编辑
编辑目前在示例程序中并不支持，但是这只是一个改变对象属性的问题。比如，改变一个 item 的 title，只需要设置title属性就好了。改变fooitem 的 parent，只需要设置parent属性为一个新值bar，所有的东西都将得到更新，bar现在有一个children为foo，因为我们使用 fetched results controllers，用户界面同样也会自动更新。
重新排序
重新排序 cell，在现有程序中也是不可行的，但是这实现起来很简单。但是，还有一个需要注意的地方：如果你允许用户重新排序，你将需要在 model 中更新order属性，并且从 fetched results controller 得到一个 delegate call（你需要忽略这个调用，因为cell已经被移动了）。这在NSFetchedResultsControllerDelegate 的文档中有解释。
保存
保存非常简单，就是在 managed object context 中调用save而已。因为我们并不直接访问 managed object context，所以是在 store 中进行保存。唯一的困难的是什么时候去保存。Apple 的示例代码在applicationWillTerminate:中执行这个操作，但是这取决于你使用情况，这也有可能在applicationDidEnterBackground:中，甚至当你程序运行时调用。
讨论
在写这篇文章和示例程序时，我初始时就犯了一个错误：我没有选择使用一个空的根 item 来作为所有用户创建的 item 的 parent，而是让它们都指向了一个nil。这将造成很多问题：因为 view controller 中的父 item 可能是nil，我们需要将 store（或 managed object context） 传给每一个子 view controller。同样的，强制 order 重新排序也非常困难，因为我们需要查找出一个 item 的所有兄弟节点，这样会迫使 Core Data 到磁盘上读取数据。不幸的是，当写这些代码时，这些问题并没有立刻弄明白，一些问题只是在写测试时才变得清晰。当我重新写代码的时候，我知道了将Store类中大部分代码移到Item类中，就这样，事情变得清楚多了。
