CODEWITHSUNDEEP
ioscore-data
Amogh Talpallikar
Amogh Talpallikar

Reputation: 12184

Should one directly use NSManagedObjects long with normal objects?

As a good design practice is it safe to start using Core Data objects as models in the application and pass them around to ViewControllers or keep all the models as NSObjects and make them responsible to create NSManagedObject and store themselves whenever we call save on them ?

Whats the general architecture to follow which will make it easy for undoing something in a particular screen and if I suddenly want to store an Object which was a normal NSObject into Core Data?

Upvotes: 1

Views: 219

Answers (1)

Leonardo
Leonardo

Reputation: 9857

In a web application much depends on the global architecture, to decide if use domain objects or placeholder objects. In Java world this means choosing between entity classes or java beans.

But in my experience, in an iOS app I have to say that it is far better to use NSManagedObject directly. There's many benefits for that, quickly I can think of three ones at the moment:

  1. Core Data is taking care of faulting when object is not needed, so you don't have to worry about memory management, and freeing of resources.
  2. Using and modifying NSManagedObjects will bring a bunch of NSNotifications that you can use to drive your UIViews.
  3. There can be benefit also when working with large set of data, i.e. UITableView and fetched controller.

Regarding the number of NSManagedObjectContext, some may find this strange but this is how I will go. If your app is simple, UITableView and some UIView detail, and you are also not planning to do some frequent very large update from the net, I think that following the Xcode template is enough. Which is, having the AppDelegate or another factory class you create (for example MyAppCoreDataController) serving one and only context, will save you lots of small problem about creating and then merging NSManagedObject and consequently refreshing the view, especially with NSManagedObject relationship.

On the other side, if for example there are data to be downloaded from the net, or you are planning to do it in a next release, there must be several context, that you later join together. You are quite obliged to do so for UI performance. Here you can choose to pass context from controller to controller, or implement some sort of logic that let you create and share same context between classes.

The point is that you can only have one view on display at a time, and this has little to do with how many contexts you have. Infact you can implement all refresh logic in view will appear/disappear.

Upvotes: 2

Related Questions