使用 NSFetchedResultsControllers 遍历一对多关系
我正在创建一个可以导航多个级别的一对多关系的应用程序。例如,假设 CoreDataBooks 代码示例以流派列表开始,您单击流派,然后获取按作者组织的图书列表如 Apple 的代码示例中所示。
这是我的问题:Apple 文档告诉我应该使用 FetchedResultsController 来帮助将我的图书列表组织成各个部分(以及其他原因)。但是,当试图弄清楚如何从“一种”类型到我的“多种”书籍时,核心数据常见问题解答告诉我们不要使用获取。来自常见问题解答:
我有从实体 A 到实体 B 的一对多关系。如何获取与给定实体 A 实例相关的实体 B 实例?
你不知道。更具体地说,不需要显式获取目标实例,您只需在实体 A 的实例上调用适当的键值编码或访问器方法即可。
当然,问题是我现在有一套书,但是我希望他们从获取结果控制器中获取它们。
继续这里的最佳方法是什么?我应该遵循常见问题解答吗?如果是,我该如何按作者将我的书籍分为几个部分?
或者我是否使用获取的结果控制器(我怀疑这更好),在这种情况下我如何遍历一对多关系(因为苹果的非常有用的答案只是“不”)?
非常感谢您的帮助。
萨莎
I am creating an app that navigates through multiple levels of one-to-many relationships. So for example, pretend that the CoreDataBooks code sample starts with a list of genres, you click on a genre and then get the list of books organized by author as seen in Apple's code sample.
Here is my problem: the Apple documentation tells me I should use a FetchedResultsController to help organize my list of books into sections (among other reasons). But when trying to figure out how to get from "one" genre to my "many" books, the Core Data FAQ tells not to use a fetch. From the FAQ:
I have a to-many relationship from Entity A to Entity B. How do I fetch the instances of Entity B related to a given instance of Entity A?
You don’t. More specifically, there is no need to explicitly fetch the destination instances, you simply invoke the appropriate key-value coding or accessor method on the instance of Entity A.
The problem, of course, is I now have my books in a set, but I want them to get them from a fetched results controller.
What is the best way to proceed here? Should I follow the FAQ, and if so, how do I manage dividing my books up into sections by author?
Or do I use a fetched results controller (which I suspect is better), in which case how do I traverse the one-to-many relationship (since Apple's oh-so-helpful answer is simply "don't")?
Many thanks for your help.
Sasha
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您的数据模型大致如下所示:
在主表中,您运行获取结果控制器来获取
Genre
对象表。然后,用户选择其中一行,在幕后选择特定的Genre
对象。由于每个
Genre
对象都有一个books
关系,指向相关的Book
对象,因此您会自动获得对所有相关书籍对象的引用,因此你不必拿任何东西。对于您的图书表格视图,您只需在所选Genre
对象的books
关系中创建一个Book
对象的排序数组。将核心数据对象图视为一团串珠串,全部编织在网络或织物中。珠子是物体,绳子是关系。抓取会从团块中拔出一个珠子/物体,但是一旦您手中拥有该珠子/物体,您就可以拉动它的绳子/关系来拉出与手中的珠子相关的所有珠子/物体。
因此,在大多数情况下,使用提取只是为了查找起始对象,然后遍历关系来查找大多数其他对象。
这就是为什么苹果文档说你不需要第二次获取。
You have a data model that looks roughly like this:
In your master table, you run a fetched results controller to get table of
Genre
objects. Then the user selects one of the row which behind the scenes selects a particularGenre
object.Since every
Genre
object has abooks
relationship that points to the relatedBook
objects, you have automatically got a reference to all the related book objects so you don't have to fetch anything. For your book tableview you just create a sorted array of theBook
objects in the selectedGenre
object'sbooks
relationship.Think of a Core Data object graph as a clump of bead strings all woven together in a web or fabric. The beads are objects and the strings are relationships. A fetch plucks one of the bead/objects from the clump but once you have that bead/object in hand, then you can just pull on its string/relationship to pull out all the beads/objects related to the bead in your hand.
So, fetches are used in most cases just to find the starting objects, then you walk relationships to find most of the other objects.
That is why the Apple docs say you don't need a second fetch.