What does MVC class organization look like for multiple views and controllers?

The idea of MVC itself seems clear to me but I have trouble understanding how the concept 'scales up' to multiple views and controllers.

It appears that Cocoa takes the approach of the controller being the 'switchboard' between the model and the view. How would the application be organize开发者_JAVA百科d and function in case of multiple views? If there is a controller associated with every view, would the main application have to keep track of all the controllers it spawns, or each controller would have 'nested' controllers it instantiates, e.g. an application would create a window, the window would create a toolbar etc?

What if the entire application would need to work with the same model, or would you break the models down into smaller ones?

It seems like what I'm really asking is how you would split a multi-window/view application into its logical blocks while retaining the modular MVC structure. I've attempted to look at code from the WordPress iPhone app as well as Adium but both seem to have a relatively large code base that I get lost in.

Generally controllers are implemented hierarchically. For example, in the standard Cocoa Document architecture, you have an NSDocumentController that manages multiple instances of NSDocument. Each instance of NSDocument manages one or more instances of NSWindowController, and each instance of NSWindowController can manage one or more instances of NSViewController.

As you move down the hierarchy, the controllers become more specific and fine-grained in their responsibilities. In terms of accessing the model, Cocoa has several patterns such as the delegate and datasource patterns which you can use to allow the view to draw without the view needing to know anything about the model itself.

Generally the app would have a single unified model, unless it makes sense to have different models (for example, if you needed your app to edit different types of document).