Reputation: 3278
I am working with Core Data and I am not sure where to actually save/fetch the data. Here is a little example:
I have a ViewController class where I want to fetch data from the NSManagedObject person and display it in a label. Now should I go ahead and create a function inside the ViewController to fetch/save data? The problem is that if I have a lot of ViewControllers where I need the same data I will have to copy the function into every ViewController.
Should I call a function inside my person class that inherits from NSManagedObject and return what I am looking for?
Is it maybe best to create a class that does not inherit from NSManagedObject that returns what I am looking for?
So what is the proper way to do this?
Upvotes: 1
Views: 180
Reputation: 28419
NSFetchedResultsController
is a class that helps control a certain aspect of core data, namely a collection of fetched objects of a single entity type.
It provides API to setup what data is desired, fetching the data, and observing changes in the data.
I suggest you use it as an example of some things you may want to provide, and write a similar controller class that provides the ability to fetch your data and observe it as it changes.
You may find that a thin veneer over NSFetchedResultsController
is all you need (for iOS). For OS X, you can utilize NSArrayController
but NSFetchedResultsController
is in general a good model to follow.
Upvotes: 0
Reputation: 999
The proper way is to apply MVC design pattern.
In your case you should separate all the fetching job ,which belongs to the model, from the ViewController and do it inside a separate class which commonly is called as "Manager" or "Service".
There you will fetch all data, handle it and then pass it to the viewController as an input so the viewController will show it in the UI.
Like this everything you do in the manager will be reusable and your code will be more organised and you will be applying the standards which help any other developer to understand easily your code and like this the cost of maintaining it will be reduced.
Upvotes: 1
Reputation: 19249
There's never a single way of achieving the same goal and most of them are valid approaches.
My usual approach is to create a 'data service' class that abstracts you from the persistence engine that you use. This will help you writing tests without the need of the real database (using a mock data service) and will improve code reuse.
I usually create an additional abstraction layer that asks my 'api service' and my 'data service' for the information that I need and return it to my controller.
For example, if I'm working on a Twitter clients, I'd probably have a TwitService
that checks if I have the information required already in the database by asking the DataService
, and will go to the ApiService
to fetch the required information if it doesn't exist. Then it will persist it into database so it's already available for next requests before returning to the caller.
This way, the view controller will simply call my TwitService
for the recent information, regardless if it's been already persisted or it'll be fetched from the Internet.
Upvotes: 1