Question

Say I have a core data model with a few entities and, throughout the application’s lifecycle, I’ll be getting and setting properties of these entities from different views.

At least to me, it seems like passing the managed object context around from view controller to view controller and having the controller’s code know about the different entities or derived objects goes against decoupling. As a matter of fact, there is a similar question where the only answer suggests passing around the managed object context.

So, in the spirit of MVC, I thought it might make more sense for view controllers to stick to controlling views, and have a singleton model controller through which these view controllers can query the model to feed their views and notify back when the model needs to be updated based on user interaction with the view.

But I’m not sure how to go about implementing the single model controller interface. For instance, here’s a few ideas:

• make this controller both a delegate and data source to all view controllers?
• have the controller be only a data source and use notifications for updates?
• kvc/o?
• is the whole idea of a centralized bridge from/to the model just overengineering the MVC pattern? That is, is there some reasonable argument in favor of instead passing the managed context around and this not being considered crappy object-oriented design?

Another thing I’m thinking is, if the singleton controller is a delegate and data source, the methods to get model data and update the model should implement some sort of visitor pattern, right? Meaning, for example, if view controller A allows the user to interact with model entity / object A and some view controller B allows for the same for a model object B, and both view controllers rely on the same delegate, the delegate will have to have some way to know which model entity it should target depending on what concrete controller is calling on it.

I’d appreciate any thoughts / ideas

Answer 1

In the end, I ended up dropping the delegate / datasource approach for a singleton pattern:

I figured the following:

• all controllers are collaborating with a single shared
  managedObjectContext
• the Core Data model itself revolves around a single “configuration”
  entity (not the configurations that the Core Data literature refers
  to).
• This “default configuration” is also what all controllers interact
  with, since all other entities exist in the context of this
  configuration entity.

So essentially, I have a shared resource which should be accessible in a way similar to a global variable.

So I encapsulated the shared resource in a Singleton through whose interface all other controllers can query and modify the model without knowing much about the internals.

The general interface allows for things like:

• [ModelControllerBridge sharedBridge] defaultConfiguration] which
  returns the default shared NSManagedObject
• [[ModelControllerBridge sharedBridge] newDataSample] which returns a
  new NSManagedObject and internally allocates and inserts it in the
  appropriate entity within the model.
• [[ModelControllerBridge] shouldCommitChangesToModel] which signals
  the context should be committed to the permanent store
• etc.