NSFetchedResultsController and constructing NSFetchRequests

Question

I have setup Core Data for an iPhone app without an instance of NSFetchedResultsController.

To do this, I created a created a model class to encapsulate all core data requests and constructing of NSFetchRequests/NSPredicates.

This kept all Core Data specific code out of my UITableViewController.

Now I want to add NSFetchedResultsController to make populating a sectioned UITableView easier.

My issue is this: In all examples I have seen the instance NSFetchedResultsController is an ivar of the UITableViewController. This leads to all NSFetchedResults statements constructed within the UITableViewController.

I feel like this is clutters the UITableViewController and adds another responsibility.

How do you deal with this?

What does your object graph look like when using NSFetchedResultsController?

Where do you construct your NSPredicates?

Answer 1

I have a bunch of methods in my model class that returns various kinds of predicates, but I construct the actual NSFetchRequest and NSFetchedResultsController in the UITableViewController subclass. The reason I do it that way is because the user can set options about what criteria he wants to include, so that's properly a view-controller-related item, and the view controller needs easy access to the NSFetchedResultsController.

If the user doesn't have any say in the matter, I'd just have the UITableViewController get a NSFetchedResultsController when it loads.

Answer 2

Update:

I've gone back to constructing NSFetchedResultsControllers within the UITableViewControllers.

I've also been using a category on NSManagedObjectContext for queries. Additionally, I have been putting more logic within categories on my NSmanagedObject subclasses.

Overall, I am happy with the architecture I have been using as of late.

---

Original Answer:

I guess I'll post my own take on the matter.

Since NSFetchedResultsController is a Foundation class and not a UIKit class, it screams model to me.

Same thing for NSFetchRequest.

It seems that constructing a an NSFetchRequest relies on knowledge of the data model, which you could argue a UITableViewController should have no knowledge of.

This leading me to several ideas about what the object graph should look like.

One option is to subclass NSFetchedResultsController and make is like a factory class, where I return fully configured instances of NSFetchedResultsController. This keeps NSFetchRequest Construction.

Another option is very similar, but instead of subclassing NSFetchedResultsController, I create a NSObject subclass or category that handles the same work.

Both of these options seem to conform to MVC better than using the UITableViewController to perform those tasks.