What should own the model in an MVC pattern?

Question

I have been making iOS apps since I can remember, but I haven't matured my programming style much until recently when I got an internship programming. I learned many OO concepts early on because I realized that life sucked with out an understanding of them, but one thing that I never made myself learn was the MVC pattern.

To give context, let's say that I'm drawing a solar system inside of a single SolarSystemView (a subclass of UIView). Should my SolarSystemView have an instance variable of class SolarSystem (a class containing a data structure with all of the important planetary and stelar properties), or should that be under ownership of an instance of a SolarSystemViewController? Or is it something completely different? I can't find any example code that gives a satisfactory answer.

I imagine that if the view owned the model, operations would be very smooth, but that also doesn't feel like good style. After all, the SolarSystem instance has to change dynamically somehow, and with the same or similar rate that the SolarSystemView updates.

Answer 1

In this case, SolarSystemView should not contain any instant of the SolarSystem class. The SolarSystemViewController should be the go between your view (SolarSystemView) and the model (SolarSystem).

Answer 2

In the MVC paradigm, the Model is supposed to be separated from the View. To get the data it needs to draw itself, it asks the Controller for it, which in turn asks the Model for it. That way, we decouple the information from the GUI. Think of it as Model Controller View if it helps. Therefore, in most cases, the Controller "owns" the Model.

For example, in cs193p, the CalculatorViewController (Controller) has a CalculatorBrain (Model) property, which it interacts with to get the results of equations to display in the View.

In your particular example, the SolarSystemViewController would probably have a strong reference to the SolarSystem, which it would poll for data that it would hand off the the SolarSystemView so that it could draw itself when it needed updating. The SolarSystemView might also notify the SolarSystemViewController when the user interacts with it so that it can display other views or update the SolarSystem, among any other tasks it could perform.

Note that the MVC paradigm in Cocoa and Cocoa Touch is a little different than the more generalized version of MVC seen elsewere, like Smalltalk. For example, if you look at the Wikipedia page on MVC the diagram there should look different than what you've been learning. In fact, GoF (Design Patterns) describes MVC thusly.

MVC consists of three kinds of objects. The Model is the application object, the View is its screen presentation, and the Controller defines the way the user interface reacts to user input. Before MVC, user interface designs tended to lump these objects together. MVC decouples them to increase flexibility and reuse. MVC decouples views and models by establishing a subscribe/notify protocol between them. A view must ensure that its appearance reflects the state of the model. Whenever the model's data changes, the model notifies views that depend on it. In response, each view gets an opportunity to update itself. This approach lets you attach multiple views to a model to provide different presentations. You can also create new views for a model without rewriting it.

In both these cases, the Model itself is contacting the View to update it. However, on iOS, interaction between the Model and the View are handled through the Controller. This is well explained in the first session of cs193p as well as Apple's own documentation on MVC relationships. That way, you only need to rewrite the Controller code to reuse the Models and Views elsewhere.

Here's the MVC diagram from cs193p to clarify.