Writing this down as a reference card:
Elements of the triad
- models a real world system by emulating its state and functionality.
- defines queries for reporting state, commands for altering state, and notifications to inform observers (that is, views) that a change has occurred
- responsible for defining the behavior.
- receive mouse and keyboard input and map this user stimulus into application response – by executing the model's command, for example.
- manages a rectangular area of the display and is responsible for data presentation and hit testing.
VIEW (listen to events from controller, read from model)
- always knows about the model, listening to messages but also reading directly from the model. It should never write to the model.
- every view keeps a reference to its model. Because a view knows about its model but a model doesn't know about a view, a single model can act as the model for many views.
MODEL (dispatch and listen to events)
- should never have a reference to the view or the controller. It communicates with other components by way of messages (loose coupling).
- export its services through queries, commands, and notifications to any interested party. Therefore, the view and controller should have one-sided knowledge of their model's capabilities.
CONTROLLER (dispatch events to view, write to model)
- knows about the model and has for job to update it in response to user interaction or system events.
- view and controllers are tightly coupled, sometimes reduced to a single class (model-view).
- typically, the controller will create the passive view (the component that don't receive any user interaction) as well as the interactive elements.
- when the controller receives a mouse event, its first order of business is to request a hit test from the view. The view returns the hit object, and the controller decides what to do with it.
[Adapted from 'Advanced Actionscript 3 with Design Patterns', by Joey Lott and Danny Patterson; Distributed MVC: An Architecture for Windows® DNA Applications]