Question

Hi
Normally all the methods like

‘- (NSFetchedResultsController *)fetchedResultsController ‘

are placed in the code of view controllers. I find it a bit messy to write Data Fetching code along with lifecycle methods or table delegate methods.
So my point is should I refactor the CoreData methods to some other helper class say DataLoader and then call them in view controllers?
Is this a wrong thing to do or am I going to loose some coding benefits of Core Data methods.

Answer 1

I would say moving the fetchedResultsController to a helper class is a good idea.
A problem I encounter often is to get the spelling of attributes right.

For example I do a predicate and want to filter on an attribute called @"isSelected". There is no check by the compiler nor by the linker to check the string isSelected. I will have to double check each line where the string has been used.

A search&replace won’t work on the misspellings because I don’t know what bugs have been introduced.

When I get the predicate wrong then no results will be fetched. Problem is that I don’t know if there are no matching rows or if I have filtered wrong. I will need to check at runtime and that consumes time.

For predicates the saved templates exist, so predicates are not a perfect example. But think about value forKey: and we are at square one.

Now if all the fetchedResultsController are in one file then checking would become easier. At least it reduces the possibility of missing that little misspelling in a far away and rarely used class.

…or am I going to loose some coding benefits of Core Data methods.

I tend to say no, but other please feel free to jump in.