NSFetchedResultsController/NSFetchRequest vs. NSManagedObject's to-many relationship

I am presenting an NSManagedObject hierarchy (basically three levels) with different view controllers on iOS. The issue I don't completely understand is that if there is need for NSFetchedResultsController for each of the view controllers. For the root view controller it seems convenient but the views that are following this are based on the selection in the previous view. What about NSFetchRequest when compared to direct relationships? The data being displayed is static and it will not change ever, so there is no need to prepare for updates. It will be loaded from a core data sqlite file.

Here's the simple graphic of what I have:

A (1) <---> (*) B (1) <---> (*) C

So both A-B and B-C relationships are one-to-many and in the root view I'm displaying a list of As. S开发者_如何转开发electing one A will display it's Bs in the next view controller and so forth.

Is there any difference whether I'm fetching the instances of B with NSFetchRequest (or NSFetchedResultsController) or simply using the to-many relationship in A? Is there any difference in memory footprint or under situations when memory is running low? I understand that I can always give the fetch controller away when didReceiveMemoryWarning, but with managed objects I think it's not that simple. Is this so? I'd love to use the direct relationships.

Thanks in advance.

There's a difference but not one you should worry about unless you have thousands of Bs and Cs for each A.

If you use the relationship then you get an NSSet back - this won't use NSFetchedResultsController. However, the objects you get back won't actually have any data in, they will all start out as faults so the memory footprint is pretty small. They only retrieve their data once you ask for it :)

And if you get a low memory warning you can force managed objects to become faults again by reloading them from the context (see the docs here).