4

I've just gotten into making applications with CoreData, but I'm familiar with MVC concepts because I used to do a lot of work in web development using (and developing) MVC frameworks.

From what I gather, CoreData automatically generates classes that inherit from NSManagedObject. The objects are created by a fetch request to the context or by inserting a new one into the context. In the apps I've seen, the objects are empty aside from properties that correspond to their attributes in the database, essentially making them objects that mimic a row in the entity's table.

It makes sense that those automatically generated classes and CoreData itself make up the applications model. In the apps I've made traditionally, there is instead a Model class that is in charge of handling all of the data. This is often a Singleton class, and each controller that needs the model can simply use self.model = [Model sharedInstance];. For bigger apps, there may be multiple models instead of one gigantic one. You get the picture. I guess my first question is: am I right? CoreData and it's associated NSManagedObject's make up the entire model for an application?

I would guess that is wrong, because an application may need other functionality that deals with data that does not have an assigned CoreData object. For example: what if a CoreData application needs to populate a table view with data that is retrieved through an HTTP request from foo.com/test (let's say it is JSON data). This data does not need to be stored in CoreData, but at the same time, I don't think retrieving and parsing the data is a job for a controller. Should there be an object, FooDataManager (or something like that) that handles the HTTP requests to manage data from foo.com (it could extend AFHTTPClient). And then controllers that deal with foo.com have a property for fooDataManager, which acts as a model for that controller? And then controllers will call [self.fooDataManager retrieveAndParseData];?

I want to verify this information before I start developing CoreData apps so that I do it correctly from the start. In web development, I'm used to having one model for each controller, but it seems like on iOS, there can be many models that all do their own thing, many controllers who use those models, and all of those models are in addition to CoreData and the NSManagedObjects.

Logan Serman
  • 29,447
  • 27
  • 102
  • 141

1 Answers1

2

From what I gather, CoreData automatically generates classes that inherit from NSManagedObject.

No. Unless you specify that a given entity uses a NSManagedObject subclass that you write, objects returned by Core Data are instances of NSManagedObject.

I guess my first question is: am I right? CoreData and it's associated NSManagedObject's make up the entire model for an application?

That depends on the application. As indicated above, if you want a given entity to map to a NSManagedObject subclass that you provide, you can do that. That'd be useful if you want your data objects to include methods beyond just the accessors for the entity's properties. For example, you might implement a -compare: method to facilitate sorting in a particular order, or a -getCurrentImage method that retrieves a product image from a web server. Also, your model might include one or more model controller classes that deal with such things as fetch requests, so that the rest of the program doesn't need to even be aware that the model uses Core Data.

an application may need other functionality that deals with data that does not have an assigned CoreData object...what if a CoreData application needs to populate a table view with data that is retrieved through an HTTP request from foo.com/test

You can absolutely put that functionality in a separate class and think of it as part of your model, and I'd say it's probably a good idea. A lot of iOS programmers would probably put it in a view controller just because it seems expedient, but I'd agree that making it part of your model is a better plan.

Caleb
  • 124,013
  • 19
  • 183
  • 272
  • In the project I inherited, there was a class for every entity. `Person : NSManagedObject`, etc. They seemed to be automatically generated, and none of them had methods in them. They were simply constructors and `@dynamic` properties. A developer (not there anymore) showed me that something in the menus of XCode that generated these classes, but I can't remember where it was... – Logan Serman Sep 07 '12 at 21:28
  • It's Xcode, not Core Data, that's generating those classes, and yes, it's basically just creating a class based on the entity you specify. (Select an entity in your model and use Editor->Create NSManagedObject Subclass.) You'd use that tool when you want to add behavior to a given entity as described above; if the classes in your project are empty, you could just as easily use NSManagedObject directly. – Caleb Sep 07 '12 at 21:40
  • I see, thanks. Going to wait a little bit for more opinions before accepting an answer. Are generating the classes better than using NSManagedObject, because they will then be strongly typed? It would also make for more readable code, yes? – Logan Serman Sep 07 '12 at 21:46