What is the organization of an MVC class for multiple views and controllers?
The idea behind MVC seems clear to me on its own, but it's hard for me to understand how the concept "scales" to multiple views and controllers.
It looks like Cocoa uses a controller approach as a "switch" between model and view. How would the application be organized and operated in case of multiple views? If there is a controller associated with each view, the main application must keep track of all the controllers it spawns, or each controller will have "nested" controllers that it spawns, for example. an application would create a window, a window would create a toolbar, etc.
What if the entire application needs to work with the same model, or you can split the models into smaller ones?
It seems that what I am really asking is how you would divide a multi-window / view application into its logical blocks while maintaining the modular structure of MVC. I've tried looking at the code from the WordPress iPhone app as well as Adium, but both seem to have a relatively large codebase that I'm getting lost in.
a source to share
Controllers are usually implemented hierarchically. For example, in the standard Cocoa Document architecture, you have NSDocumentController
one that manages multiple instances NSDocument
. Each instance NSDocument
manages one or more instances NSWindowController
, and each instance NSWindowController
can manage one or more instances NSViewController
.
As you move through the hierarchy, controllers become more specific and precise in their responsibilities. In terms of accessing the model, Cocoa has several templates, such as the delegate and data source templates, that you can use to let you draw a view without the view, which you need to know about the model itself.
In general, an application will have a single unified model if it doesn't make sense to have different models (for example, if you need an application to edit different types of documents).
a source to share