The Model View Controller:

a Composed Pattern.

Toni Sellarès
Universitat de Girona

The Model-View-Controller (MVC) Pattern

The MVC pattern separates the modeling of the domain, the presentation,
and the actions based on user input into three separate classes:

Model:

- Contains data.
Views and Controllers conform
- Encapsulates application state.
the User Interface.
- Responds to state queries/updates.
- Exposes application functionality.

View: A change-propagation mechanism

ensures consistency between the
user interface and the model.
- Renders the model.
- Allows Controller to select view.
- Sends user input to the Controller.
In general all GUI toolkits are
Controller:
developed according to MVC
principles.
- Defines application behavior.
- Maps user actions to Model updates.
MVC: Flow
The user manipulates a view and, as a result, an event is
generated.

Events typically cause a controller to change a model, or

view, or both.

Whenever a controller changes a model’s data or

properties, all dependent views are automatically updated.

Similarly, whenever a controller changes a view, for

example, by revealing areas that were previously hidden,
the view gets data from the underlying model to refresh
itself.

Observe that:
• Both the view and the controller depend on the model.

• The model depends on neither the view nor the controller.

• The separation between view and controller is secondary in many rich-client applications,
and, in fact, many user interface frameworks implement the roles as one object.

MVC: Benefits
• Supports multiple views. Because the view is separated from the model and there
is no direct dependency from the model to the view, the user interface can display
multiple views of the same data at the same time.
• Accommodates change. User interface requirements tend to change more rapidly
than business rules. Because the model does not depend on the views, adding new
types of views to the system generally does not affect the model. As a result, the
scope of change is confined to the view.
• Complexity. The MVC pattern introduces new levels of indirection and therefore
increases the complexity of the solution slightly. It also increases the event-driven
nature of the user-interface code, which can become more difficult to debug.
• Cost of frequent updates. Decoupling the model from the view does not mean
that developers of the model can ignore the nature of the views. If the model
undergoes frequent changes, it could flood the views with update requests. As a
result, the view may fall behind update requests. Therefore, it is important to keep
the view in mind when coding the model.
Looking at MVC through other patterns
MVC is set of patterns together in the same design:

- Model uses Observer to keep

views and controllers updated on the
latest state changes.

- View and Controller implement

Strategy Pattern Controller is the
behavior of the view and can be
easily exchanged with another
controller if you want different
behavior.

- View also uses a pattern internally to

manage the windows buttons and
other components of the display: the
Composite Pattern

The Observer Pattern in the MVC

Meet the MVC

Picture your favorite MP3 player:

– You can use its interface to add new songs, manage play lists
and rename tracks.

– The player maintains:

• Database of all your songs along with associated names and data.
• Plays the song.
• Updates the interface constantly with current song, running time and so
on

Meet the MVC

The view display is You use the

updated for you. interface and your
actions go to the
You see the song
controller
display update and “Play new song”
hear the new song
playing

Controller
View
Controller asks
Model tells the view
Player model to
the state has
begin playing the
changed
class Player { song Controller
play ( ) { }
manipulates the
rip ( ) { }
model
burn ( ) { }
The model notifies }
the view of a change
in its state.
The model contains all the state,
Model data, and application logic needed
to maintain and play mp3s.
A Closer Look….
Lets see the nitty gritty details of how this MVC pattern works.

MODEL:
The model holds all the data,
CONTROLLER: state and application logic. The
VIEW: Takes user input and figures model is oblivious to the view
Gives you a presentation of the out what it means to the model. Here’s the and controller, although it
creamy
model. The view usually gets provides an interface to
controller;
the state and data it needs to manipulate and retrieve its
it lives in
display directly from the state and it can send
the middle.
model. notifications of state changes
to the Observer.

(1) The user did something

Controller
(2) Change your state
(3) Change your display
class Player {
play ( ) { }
rip ( ) { }
(4) I have changed
burn ( ) { }
}
View
Model
This is the user interface
(5) I need your state information
Here’s the model; it handles
all application data and logic.

Observer

(1) The user did something

Controller
(2) Change your state
(3) Change your display
class Player {
play ( ) { }
rip ( ) { }
(4) I have changed
burn ( ) { }
}
View
Model
(5) I need your state information

The model implements the Observer Pattern to keep

the interested objects updated when the state
Observer: changes occur. Using the Observer Pattern keeps the
model completely independent of the views and the
controllers. Its allows us to use different views with
the same model, or even multiple views at once.
Observer
(1) You are the user: you interact with the view:

– The view is your window to the model. When you do something to the view (like click the Play button), then the view
tells the controller what you did. It’s the controller’s job to handle that.

(2) The controller asks the model to change its state:

– The controller takes your actions and interprets them. If you click on a button, it’s the controller’s job to figure out what
that means and how the model should be manipulated based on that action.

(3) The controller may also ask the view to change:

– When the controller receives an action from the view, it may need to tell the view to change as a result. For example, the
controller could enable or disable certain buttons or menu items in the interface.

(4) The model notifies the view when its state has changed:

– When something changes in the model, based on either some action you took (like clicking a button) or some other
internal change (like the next song in the playlist has started), the model notifies the view that its state has changed.

(5) The view asks the model for state:

– The view gets the state it displays directly from the model. For instance, when the model notifies the view that a new
song has started playing, the view requests the song name from the model and displays it. The view might also ask the
model for state as the result of the controller requesting some change in the view.

All these observers

Observer will be notified
whenever state
changes in the
model.
Observers

My state has changed

Observable

class Foo {
void bar ( ) {
doBar();
}
} View

Model

I’d like to register

as an observer Controller View

Any object that’s

interested in state
changes in the model
registers with the
model as an
View observer.
The model has no dependencies on
viewers or controllers!
 Strategy
The View and the Controller implement the classic Strategy Pattern: the view is an
object that is configured with a strategy. The view is concerned only with the visual
aspects of the application, and delegates to the controller for any decisions about
the interface behavior. Using the Strategy pattern also keeps the view decoupled
from the model, because it is the controller that is responsible for interacting with
the model to carry out user requests. The view knows nothing about how it gets
done.

(1) The user did something

Controller
(2) Change your state
(3) Change your display
class Player {
play ( ) { }
rip ( ) { }
(4) I have changed
burn ( ) { }
}
View
Model
(5) I need your state information

Strategy

The controller is the

The view delegates to the strategy for the
controller to handle the view -- it’s the
user actions. object that knows
The user did something how to handle the
user actions.

Controller

View

Controller
We can swap
another behavior for
the view by changing
the controller.
The view only worries about presentation, the
controller worries about translating user input to
actions on the model.
Composite

(1) The user did something

Controller
(2) Change your state

(3) Change your display

class Player {
play ( ) { }
rip ( ) { }
(4) I have changed
burn ( ) { }
}
View
Model
(5) I need your state information

The display consists of a nested set of windows, panels, buttons, text

labels and so on. Each display component is a composite (like a window) or
a leaf (button). When the controller tells the view to update, it only has
to tell the top view component, and the Composite takes care of the
rest.

Composite

paint ()

Window

Set BPM

Set
<< >>
View

The view is a composite of GUI components

(labels, buttons, text entry, etc.). The top level
component contains other components, which
contain other components, and so on until you get
to the leaf nodes.
Summary
• The MVC Pattern is a compound pattern consisting of the Observer,
Strategy and Composite patterns.

• The model makes use of the Observer pattern so that it can keep observers
updated, yet stay decoupled from them.

• The controller is the strategy for the view. The view can use different
implementations of the controller to get different behavior.

• The view uses Composite Pattern to implement the user interface, which
usually consists of nested components like panels, frames, and buttons.

• These patterns work together to decouple the three players in the MVC
model, which keeps designs clear and flexible.

• The Adapter pattern can be used to adapt a new model to an existing view
and controller.