what's the most appropriate pattern to get and set core data model from multiple view controllers?

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.

Answer 2

It seems to me that your biggest concern is with passing the model around from controllers. It is perfectly alright for the controllers to reference and use the model, but trying to manage their creation and penetration, you're right, is a bit much.

I'd recommend using a Dependency Injection container that can generate the access layer to your model. This way the controllers will get the model passed to them via DI, w/o having to pass around how to create the model classes.

The idea of a single centralized bridge isn't a bad one either, but it would make things a little tricky to unit test.

Answer 3

Your idea of a "model controller" makes sense, the problem is I think you may be thinking of it wrong.

It's not really a "model controller," it is the model. In MVC (traditionally), the views communicate with their controller for advice on what to do with interactions, and the controller decides what to tell them based on its logic and information it gathers from the model.

So really, you're simply abstracting the model further, which is a good thing. The idea of a "centralized bridge" is what you want in MVC. Your controller should see a high-level abstraction of the underlying model's implementation, as with all interfaces and layers of abstraction.

As far as implementing the model goes, I'm not sure which is the "best" way to do it, but I can't imagine using the delegate/data source strategy (or sending notifications to the controller) would be detrimental, I'd guess it depends on what you're comfortable with. If you love KVC/KVO, I doubt it'll hurt you. As far as the visitor pattern goes, the logic concerning keeping track of which controller gets which object should be within the model.