Understanding Model-View-Controller

问题:

I have an app where I want to have one “background” view (view controller view), and on top of that, multiple UIViews that draw themselves as circles. I just don't understand how to implement all of this while still adhering to MVC...

The model and the view should be different. Does this mean that I generally need one set of header and implementation files for the view and another (separate) set for the model — even if my object is just a Circle class? Or, would I have one Circle.h and Circle.m set, and then inside the header file have two interface blocks, one for the model and one for the view, and two implementation blocks (again, one for the model and one for the view)?

I’ve seen a few people recommend using the view controller to handle all of the views in loadView, and to avoid creating separate custom view objects; does this mean that I shouldn’t create a separate set of .h and .m files for the view? The latter seems a lot more organized in terms of design to me.

Also, if I were to have multiple view objects and multiple model objects handled by the view controller, I would store these in two arrays in the controller — one for models, and another for views. Right? My question is: When I use key-value observing on each model, how would I, for each model object, alter the correct corresponding view object (assuming that indexes are not the same for both objects in both arrays)?

I was thinking about using a pointer to the model object inside of the view, and KVOing from the view to the model — but then it doesn’t go through the controller and thus breaks MVC altogether, right?

Thank you in advance.

回答1:

MVC is a big, broad idea. It's more a guiding philosophy than a specific rule, and it's not always implemented the same way. Read Apple's discussion of MVC to appreciate the difference between traditional MVC and MVC in Cocoa.

It's hard to say how to apply MVC to your app because you haven't told us what the app should do, and also it doesn't sound like a realistic application. So I'll do my best here and make some assumptions along the way. An app that just draws a bunch of circles in fixed locations on a background isn't very interesting -- it could be almost all views, barely any need for a controller at all. So lets say that the circles are all moving in different directions, are drawn in different colors, and change in size over time. Now you start to have a need for a model, so that you can keep track of the data that these circles represent, and a controller to translate the model into terms that can be represented by the views.

Since you asked specifically about drawing circles, lets start with the view. It seems like a good idea to have a custom view that knows how to draw a circle given the necessary parameters: area, color, and position. You'd probably make these things properties, and override -drawRect: such that it draws a circle of the given area in the given color.

We don't know what these circles represent, but it's not much fun if they don't represent something, so let's postulate that the app's job is to help us compare corporations. We have data on revenue, market capitalization, number of employees, credit rating, name, ticker, etc. You could create a custom object to store all the data for each corporation, or you could put it all in a dictionary. Our model is a set of these custom objects or dictionaries.

Notice that the circle views don't know anything about corporations, and the model doesn't know anything about circles. This is A Good Thing. It's also where the controller comes in. The controller is where you put the code that expresses the model visually using the views. It also interprets events from the views, updating the model as necessary. So, our controller knows both about the particulars of the corporations, and the properties of the circle view. It creates a circle view for each corporation in the model. I want the area of a circle to correspond to the corporation's market cap, the vertical position to represent the revenue, and the horizontal position to indicate number of employees. We'll assign a color based on the corporation's credit rating. The controller should, of course, keep track of all the circle views and some way to map between circle views and corporations.

Now you've got something. It's still a pretty simple application, but you've got a useful chart comparing corporations in several dimensions. Let's improve it.

First, it's hard to know which circle represents which corporation. It would be nice if a circle view could optionally display some text. Let's add title and subtitle properties, and modify -drawRect: to draw these strings above and below the circle, respectively. We'll also change the controller so that a tap or click on a circle sets the title and subtitle of that circle to it's corporation's name and ticker symbol, or clears them if they were previously set.

Second, it's nice to compare corporations at a moment in time, but more interesting if we can show changes over time. Let's change the model to include historical data for revenue, market cap, employees, and rating. We can update the controller so that it can uses the historical data to animate the circles.

The first change related to how we draw information on the screen, and didn't require any modification to the model at all. The second change was about what data we have to work with, and didn't require any change to the view at all. You could easily re-use the circle view to represent some other kind of data, or maybe even to be the puck in an air hockey game. It's just a colored circle. And you could re-use the model in another app that deals with the same kind of data.

I'm sure the hypothetical application in this very long-winded explanation-by-example bears roughly zero resemblance to your own application, but perhaps it'll help to explain why MVC is useful and inform the structure of your own application. Good luck.

回答2:

I got good explanation from CS193P IPHONE APPLICATION DEVELOPMENT (Winter 2013).

Model-View-controller:

Divide all objects into three camps:

Model : What your application is (A Card , A Deck , card game logic)
Controller : How your model is presented to user (UI Logic). Controller knows everything about the UI.
View : Your controller's minions.

How those camp communicate :

Don't cross yellow line.
You can cross over Dashed white line.
some special rules are there for crossing solid white line.

Controller --> View (via Outlet)
View --> Controller (via Data source (count, dataAt), delegate(will, should, did), Target-action)
Model --> Contoller (via Notification & Key Value Observing)