Core Data: Relationship 总结

本文部分内容来自 Objc.io 的《Core Data》一书，买来一个月后觉得39美元总体还是花得值得的，推荐购买。

Fetch requests 并非获取 managed objects 的唯一途径，而且，应该尽可能避免 fetch。因为 fetch 操作会遍历整个 Core Data Stack，代价很大，是重大的性能瓶颈。获取 managed objects 的另外一个重要途径是 relationship。

Creating Relationships

一般关系

Relationship 有三种：一对一(to-one)，一对多(to-many)，多对多(many-many)。多对多关系的对应关系也应该是多对多关系。建立关系时尽量避免单向关系，这样不利于 Core Data 维护对象之间的关系。在 Model Editor 里设置关系时注意设置逆向关系 Inverse Relationship，这样 Core Data 可以替我们完成很多工作。

部门 Department 和职员 Employee 的关系设置：

Relationship of Department and Employee

这里部门与职员的关系是一对多，职员与部门的关系是一对一。
一对一关系和 managed object 的其他属性没有多大区别，Xcode 生成的子类里该关系的属性类型就是关系目标的类型；一对多关系里，为了保持维护的对象唯一，子类使用 Set 来维护对对象的引用。若勾选了 Ordered，则使用 NSOrderdSet 类。使用有序关系并没有真的对里面的对象进行排序，只是方便了索引。

extension Department {
    @NSManaged var name: String?
    @NSManaged var employees: NSOrderedSet?
}
extension Employee {
    @NSManaged var name: String?
    @NSManaged var department: Department?
}

不一般关系⊙▂⊙

上面的例子里关系目标都是其他实体 Entity，关系也可以指向自身类型的 Entity，比如，利用 Person 建立一个族谱，那么关系的目标对象都是 Person。这里除了关系引用的是自身类型，也没有什么特别的了。
还有一种比较特别：单向关系。上面也提到了，尽量不要建立单向关系。因为在单向关系里，一方被删除了的话，另一方无法得知。使用单向关系时必须小心。
PS: Core Data 不支持跨 Store 的关系。

Accessing and Manipulating Relationships

访问关系

访问关系有两种途径，一种是和访问普通的对象属性一样：

 let employees: NSOrderedSet = aDepartment.employees
 let department: Department = anEmployee.department

另外一种是使用 KVC 方法，如果传递的 key 不是 Modal 里定义的属性，将会抛出异常：

let employees = aDepartment.valueForKey("employees") as? NSOrderedSet
let department = anEmployee.valueForKey("department") as? Department

除此之外，关系还支持 keypath 访问，path 支持普通的属性 perporty 和关系 relationship:

let departmentName = anEmployee.valueForKeyPath("department.name") as? String

修改关系

修改关系这件事需要好好说明一下：我们只需要修改关系一方，Core Data 会自动替我们处理好剩下的事情。比如下面的情况：

transfer to new department

只需要：

//方法1：
anEmployee.department = newDepartment
//方法2：
anEmployee.setValue(newDepartment, forKey:"department")

或者：

//如果没有勾选 Ordered 选项，使用 mutableSetValueForKey(_:)
newDepartment.mutableSetValueForKey("employees").addObject(employee)
//如果勾选了，使用 mutableOrderedSetValueForKey(_:)
newDepartment.mutableOrderedSetValueForKey("employees").addObject(employee)

只需要使用上面的一种方法就可以了。
如果像批量更改部门的职员构成怎么办，单个移除以及添加很麻烦，使用 KVC 方法。

newDepartment.setValue(newEmployees, forKey:"employees")

在 Department 这一端，因为直接访问employees得到的一个无法更改的量，只能使用mutableSetValueForKey(_:)或mutableOrderedSetValueForKey(_:)来进行个体的修改，或者使用setValue(_, forKey:)来进行整体的修改。处于性能的原因，set:这类方法比如setEmployees:不能用来修改关系。
NSManagedObject重写了valueForKey:和setValue:forKey:以及mutableSetValueForKey(_:)这三个 KVC 方法，当 key 不是在 modal 里定义的属性时，这三个方法都会抛出异常。你不应该在子类中重写这三个方法。

Delete Rule

上面只需要在修改一端修改关系剩下的事情由 Core Data 替我们处理了得益于 Delete Rule 的设计。删除规则决定了删除对象时它的关系怎么处理的行为。Core Data 提供了四种删除规则，下面还是用部门与员工之间的关系来举例：

拒绝 Deny
如果关系目标里还有对象，比如要删除（撤销）某个部门，但该部门还有一个员工，那么是无法删除（撤销）该部门的，只有该部门里所有的员工被调往其他部门或是被删除（解雇）了才能删除（撤销）该部门。
失效 Nullify
移除对象之间的关系但是不删除对象。只有当一方关系是可有可无的时候才有意义，比如员工有没有部门都无所谓，那么删除该对象时只会将其关系设置为空而不会删除对象本身。
连坐 Cascade
在这种规则下，可以把一个部门一锅端。删除（撤销）某部门，部门里的员工也会被全部解雇（删除）。
不作为 No Action
什么也不做。部门被删除（撤销）后，里面的员工还不知道，以为自己还在这个部门工作呢。
前三种删除规则还是比较清晰的，都有合适的使用场景，而最后一种比较危险，需要你自己来确定关系里的对象是否还存在。

Relationship Faults

访问 managed object 的 relationship property 时，relationship 对应的 managed object 如果在 context 中不存在，那么被 fetch 进内存时会处于 faults 状态，即使已经存在也不会主动填充 managed object 中的数据，无论原来的 managed object 处于 faults 状态还是已经填充了全部数据。而且，无论是 to-one relationship 还是 to-mant relationship都是这样。这个特性对于维持较低的内存占用具有重要意义。
Relationship faults 有两层：访问 relationship 时，这时候 Core Data 做的仅仅是根据 relationship 的 objectID 来获取相应的 managed object，并不会填充数据；访问 relationship 上的某个属性时，relationship 才会填充该属性对应的数据。

Reference Cycles

关系一般都是双向的，而且关系并不想其他对象一样有强引用和弱引用的区别，在这种情况下，当关系的双方都在内存中后，自然而然就形成了引用循环。打破引用循环的唯一方法是刷新关系中的一方，使用 context 的refreshObject(_:mergeChanges:)来刷新对象。

context.refreshObject(managedObejct, mergeChanges:false)

参数mergeChanges为 false 时，对象会重新进入 faults 状态，这会移除对象里所有的数据，包括与其他对象之间的关系。需要注意的是，在这个参数配置下，该方法会放弃对象身上所有没有保存的变化。
至于何时打破引用循环这取决于应用自身的需要。比如，将当前的 ViewController 从 stack 中移除，你不再需要这些数据了，可以将对象转变为 faults状态；或者应用进入后台，你也可以这样做降低内存占用避免被系统杀掉。