Model-View-Controller
Architecture
Give someone a program, you frustrate them for a day;
teach them how to program, you frustrate them for a
lifetime.
— David Leinweber
2
Model-View-Controller
u Architecture for interactive apps
• introduced by Smalltalk developers at PARC
u Partitions application so that it is
• scalable
• maintainable
View
Model
Controller
What is MVC?
The Model View
Model
Controller
u Most programs are supposed to do work, not just be
another pretty face
• but there are some exceptions
• useful programs existed long before GUIs
u The Model is the part that does the work--it models
the actual problem being solved
u The Model should be independent of both the
Controller and the View
• But it provides services (methods) for them to use
u Independence gives flexibility, robustness
5
The View View
Model
Controller
u Typically, the user has to be able to see, or view,
what the program is doing
u The View shows what the Model is doing
• The View is a passive observer; it should not affect the
model
u The Model should be independent of the View, but
(but it can provide access methods)
u The View should not display what the Controller
thinks is happening
6
The Controller View
Model
Controller
u The Controller decides what the model is to do
u Often, the user is put in control by means of a GUI
• in this case, the GUI and the Controller are often the same
u The Controller and the Model can almost always be
separated (what to do versus how to do it)
u The design of the Controller depends on the Model
u The Model should not depend on the Controller
7
Controller Communication
View
Model
Controller
u Communicates with view
• determines which objects are being manipulated
u e.g., which object was selected with mouse click
u Calls model methods to make changes
• model makes change and notifies views to update
Advantages
u Input processing is separated from output
processing.
u Controllers can be interchanged, allowing different
user interaction modes.
u Multiple views of the model can be supported easily.
Other ways
u Combining Controller and View
• Small programs
• May be highly interdependent
• Never mix model
View
Model Controller
Other Ways
• No Model-View interaction
• All interaction happens through controller
• Controller talks to Model and View
• Your project
View
Model
Controller
Why MVC?
u Provides a logical structure for
heavily interactive system
u Adheres to good engineering design
principles and practices
• Information hiding, less coupling,
simplicity, etc.
• Delegated control style
Why MVC?
u Combining MVC into one class or using global
variables will not scale. Why?
• model may have more than one view
u each different & needing update on model changes
u Separation eases maintenance. Why?
• easy to add a new view later
u may need new model info, but old views still work
• can change a view later
u e.g., draw shapes in 3-d
• recall that the view handles selection
What s the point?
u It’s just plain easier
• (even if it doesn t look it)!
u Studies show that most introductory CS
college students tend to clump a UI
program into one big monolithic main
class
u Unfamiliarity stems from student
tendency to program according to styles
presented in textbooks and not being
introduced to design principles early
