Model-View-Controller (MVC)
I. DEFINITION
first introduced by Trygve Reenskaug (Smalltalk dev. at Xerox Palo Alto Research Center,
1979)
helps decouple data access and business logic
three elements
1. Model
o represents data and the rules that govern access to and updates of this data
o software approximation of a real-world process
2. View
o renders the contents of the model
o specifies exactly how the model data should be presented
o if model changes => the view must update its presentation as need
- push model: the view registers itself with the model for change
notifications
- pull model: the view is responsible for calling the model when it need to
retrieve the most current data
3. Controller
o translates the user's interactions with the view into actions that the model
performs
o user's interactions being: button clicks, menu selections, …
o may also select a new view – e.g. a web page of results – to present back to
user
II. INTERACTIONS BETWEEN MVC COMPONENTS
the view registers as a listener to the model => any change in the model results in a
broadcast change notification in the view (push model)
this method is not aware of the view or controller – just broadcasts change
notifications to all listeners interested
the controller is bound to the view => any user action performed on the view will
invoke a registered listener method in the controller class
the controller is given a reference to the underlying model
once a user interacts with the view, the following occurs
- the view recognizes a GUI action occurred, using a listener method that is
registered to be called when such an action occurs
- the controller accesses the model, possibly updating it in a way appropriate to
the user's action
- if the model has been altered, it notifies all interested listeners, such as the
view, of the change.
- the controller may also be responsible for updating the view
because the model doesn't carry a reference to the view, but uses an event-notification
model => many views can have the same underlying model
III. MODIFYING THE MVC DESIGN
place the controller between the model and the view
notification of state changes in model objects are
communicated to the view through the controller
=> the controller mediates the flow of data between
model and view in both directions
both the view and the model will be registered with
the controller
once a user interacts with a view, the events are
the following:
- the view recognizes that a GUI action
occurred, using a listener method.
- the view calls the appropriate method on the
controller
- the controller accesses the model, possibly updating it in a way appropriate to
the user's action
- if the model changes, it notifies interested listeners of the change => here the
change is sent to the controller
using this modified MVC helps to decouple more the model from the view