Model View Controller
M2-Software Architecture
Spaghetti Code vs Modular Design
• Spaghetti Code
• Haphazard connections, probably grown over
time
• No visible cohesive groups
• High coupling: high interaction between random
parts Both examples have 10
• Understand it: all or nothing modules and 13
connections!
• Modular System
• High cohesion within modules
• Low coupling between modules
• Modules can be understood separately
• Interaction between modules is easily-
understood and thoroughly specified
Before standard pattern
• Page wise design
• Scripting languages at runtime
• Client – server modeling
• Frontend – backend separation
• Frameworks for ease of use
The MVC Architectural Pattern
:: Introduction
• MVC was first introduced by
Trygve Reenskaug at the Xerox
Palo Alto Research Center in
1979.
• Part of the basic of the Smalltalk
programming environment.
• Widely used for many object-
oriented designs involving user
interaction.
• A three-tier architectural model:
MVC and Observer in C++ 4
The MVC Architectural Pattern
:: Model
Manages the behavior and data of the application domain,
The Model is the part that does the work--it models the actual problem being solved
The Model should be independent of both the Controller and the View
But it provides services (methods) for them to use
• Responds to requests for information about its state (usually from the view),
• Responds to instructions to change state (usually from the controller).
• In event-driven systems, the model notifies observers (usually views) when
the information changes so that they can react. (see observer pattern)
• In enterprise software, a model often serves as a software approximation of a
real-world process.
• In a game, the model is represented by the classes defining the game entities,
which are embedding their own state and actions.
MVC and Observer in C++ 5
The MVC Architectural Pattern
:: View
Renders the model into a form suitable for interaction, typically a user interface element.
Multiple views can exist for a single model for different purposes.
The view renders the contents of a portion of the model’s data.
The View is a passive observer; it should not affect the model
If the model data changes, the view must update its presentation as needed. This can be
achieved by using:
a push model, in which the view registers itself with the model for change notifications
(see the observer pattern)
a pull model, in which the view is responsible for calling the model when it needs to
retrieve the most current data.
MVC and Observer in C++ 6
The MVC Architectural Pattern
:: Controller
Receives user input and initiates a response by making calls on appropriate model objects.
Accepts input from the user and instructs the model to perform actions based on that input.
The controller translates the user's interactions with the view it is associated with, into
actions that the model will perform.
A controller may also spawn new views upon user demand.
The Controller decides what the model is to do
Often, the user is put in control by means of a GUI
in this case, the GUI and the Controller are often the same
The Controller and the Model can almost always be separated (what to do versus how to do it)
The design of the Controller depends on the Model
The Model should not depend on the Controller
MVC and Observer in C++ 7
Advantages
Separation of application logic and web design through the MVC pattern
MVC defines interaction between components to promote separation of concerns
and loose coupling
•○ Each file has one responsibility
•○ Enables division of labour between programmers and designers
•○ Facilitates unit testing
•○ Easier to understand, change and debug