In learning about Core Data, I’ve noticed how (in Xcode’s templates) Apple directly used the query classes inside the view controller. This seems like it is bad MVC (having database access logic directly inside the view controller). Would it make sense to abstract out these kinds of actions to a separate suite of classes that obtain the data from the database and pass it back to the view controller calling it?
EDIT–
So, just to be clear, when I say “kinds of actions”, I specifically mean CRUD Operations. Though if you have ideas about other things that a so-called “Model-Controller” would do, I’d be interested in hearing about them.
It’s a matter of opinion, and often yes the templates are the most simple form of working example. It’s hard to have a template spin out multiple files, for example.
Yes, personally, I generally spin out a separate NSManagedObject subclass. I like to have a _MySubclass object that has all the auto-generated stuff, then have the model actually reference MySubclass which has model-based business logic (you can use mogenerator or other methods to do this too if so inclined). Perhaps thinking of it as “Model-Controllers” and “View-Controllers” is another way of putting it.