When working with Core Data, do you keep a non managed object class, and a managed object version of it

1k views Asked by At

I've always wondered when working with core data if there is any value to have model classes that aren't managed objects? If instead to give those objects persistence, your data manager class that handles the core data store knows how to write your instances of a class(or classes) into the core datastore, and when your app wants to recall those instances from persistence, the datastore has a method that creates instances of those objects without a managed object context?

The way I learned to work with core data, is to create model classes using the managed object model that xCode gives you and then whenever you create or destroy instances of those classes you treat them as managed objects instead of the normal kinds of object instances that most other classes create. This always struck me as somewhat convoluted and difficult because whenever you need to change your managed objects you need to do it through the managed object context, which at the end of the day is just a database.

Sorry if the question is confusing, if you need clarification I'm more than happy to, I find discussing Core Data somewhat difficult.

1

There are 1 answers

1
zpasternack On BEST ANSWER

I have an app that relies pretty heavily on Core Data.

No, I don't believe there's any value in having a non-managed version of your model objects. It would only add complexity (you've got a bunch of extra code to write), and it would take away some of the benefits of using Core Data (mainly, the lazy loading of objects).

You do create and destroy managed objects through the managed object context, but other than that, managed objects act identically to non-managed ones. For example, you can change properties of managed objects without doing anything with the managed object context.

Core Data isn't really a database; it's more like an ORM (though Apple doesn't refer to it as such). It's a way to persist objects to and retrieve them from a persistent store, and it does far more than storing stuff in a database.

If you really want to have non-managed data models, my suggestion would be to not use Core Data at all. Something like Gus Mueller's FMDB or Marco Arment's FCModel.

Some aspects of Core Data are hard to get your head around, for sure. But once you figure it out, it's not so bad, and it makes certain things a lot easier than just using a database.

You can read the Core Data Programming Guide, but I personally didn't have much luck with that when first learning about it. A good Core Data book would probably be good though; when I was first learning it, I read Core Data for iOS, and found it to be quite helpful.