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