Model View Controller
A Pattern that Many People Think They Understand, But Has A Couple
Meanings
The Source of the Problem
The “Model”• We Want It to Be Completely Separate From
the Other Thing• Can potentially have several “views” – maybe
a GUI interface and a web interface• We want to test it independently
Everyone agrees about this part. Please please please keep your model separate. If you do that, your design will be 90% of the way to being good.
Smalltalk-80
The very first GUI system. Also one of the first object-oriented languages.
A Completely Novel Problem
If the right mouse button should be clicked here, what should it do?
Hmmm…seems like depends
Click!
1. The user is clicking on a variety of different regions. Each reason has a different meaning.
2. Sometimes a click has a meaning for what we might think of as “the view” – it’s moving a window (say). It really has nothing related to taxes or whatever our program is meant to do.
3. Sometimes a click has a meaning for what me might think of “the model”. It means we should change the tax rate or load a file or whatever.
The View: Handles rendering The Controller: Handles input
An Exciting New Solution: The Controller
The Model: Handles actual data
The view gets updates using the observer pattern
Updates the view based on input
Updates the model based on input
The Controller Was Actually More Complex Than You Think
The Original Model View Controller
• A Good Idea• Separated the Model from everything else• The Controller handled User Input, but also
was this smart object that knew about both the “Model” and the “View”
• And also how you built GUIs in Smalltalk (think of it as like Swing)
…but we don’t often think about GUIs in the same way today
Our GUIs are collections of interacting “widgets”. We don’t usually think in terms of targeting mouse clicks but in terms of handling “events” like buttons
being pressed.
How Does the Role of the Controller Change?
1. The controller needs to be (more/less) aware of updating the view. That is, it needs to be (more/less) aware of handling things like list box scrolling.
2. The controller needs tobe (more/less) aware of sub-widgets. That is, it needs to be (more/less) aware of creating (say) 8 different buttons and how they all should change the model (or view)
When you’re dealing with aggregated pre-built widgets
• You generally stop caring about details of input (e.g. where the mouse is)
• You generally have a ton of complexity setting up those pre-built widgets
• The “view” to the extent it is made by pre-built widgets, can’t know anything about your model
Model/View/Mediator
The Model: Handles actual data
The Mediator (a.k.a. Controller) : Sets Up and Maintains Relationship
Between The View and Model. Often with tons of observers.
The “View”: Just a bunch of glued-together widgets from a widget
library
So We’re Done Right?
The “New” MVC: Model View Mediator
The Old MVC: Model View Controller
The “New” MVC: Model View Mediator
This is potentially a terrible design
Two Scenarios
You’ve got a banking application. The Model handles details of withdraws, deposits, etc. Consider these two situations:
1. The bank discovers that customers accidentally omit a period in their withdrawls. So they enter 7500 instead of 75.00 dollars. A decision is made to pop up a warning dialog to ask them to confirm withdrawals of over 1000 dollars. Where should the code for bringing up this dialog go?
2. The bank discovers some customers have really old monitors and can’t use the new high resolution app. So we’re going to have two GUIs “standard” and “low-rez”. As the app starts, the resolution gets checked and the decision is made.
M=1 V=2 C=3
The “New” MVC: Model View Mediator
Coupled to both the view and model. Has a tendency to get fat.
http://www.sitecrafting.com/blog/model-view-1/
The “New” MVC: Model View Mediator
http://www.sitecrafting.com/blog/model-view-1/
Use lots of fancy design here to keep this extra thin
Keeping it Thin• Try this scenario:
– You’ve built two interfaces to Tivoo, a text based on that works on the console and a Java GUI one in Swing.
– Think about selecting a file. Imagine that the file has a parse error. In the GUI version, you want to bring up a new window with the entire offending file in a scroll pane, the bad line highlighted. In the text version, you want to display the 2 lines around the offending line, with the line highlighted in a different text color
– Think about what classes and functions exist in the model, the view, and the controller– How can you handle this in a way that’s generic:try {
tivooParser.parseXML(document);} catch (ParserError p) {
//what should go here//hint – I’ll want to call the controller
//hint – we want as much in the model as possible, as much // in the view as possible}
The “New” MVC: Model View Mediator
http://www.sitecrafting.com/blog/model-view-1/
Custom GUI Code, But Still Leaves As Much of the Thinking as Possible to
the Model
Calendar – Detecting Too Near1. The Calendar widget itself should not know about being “too near”. Instead, after a
particular event is dropped on the calendar, the controller should run “validateNearness” on the calendar and pop up an error message if the nearness is violated.
2. The Calendar widget should not know about nearness, but should have an idea of “event drop problem” and “time to highlight with color”. As the user drags an event around the calendar, the controller should run “validatePossibleEventTime” and “getOptimalTime” on the model. Then the controller sets the highlights on the various parts of the calendar to indicate problems.
3. The Calendar widget should know about nearness, but it should query the model for (given a particular event) what it should highlight as the maximum nearness and time to highlight as optimal.
4. The Calendar widget should know about nearness, what the optimal distance between events is, and highlight it as the user moves and creates events. But it should get the values it uses for the maximum nearness and optimal distance from the model as it starts up.
Model View Coolthing
The “New” MVC: Model View Mediator
Written in HTML/Javascript with embedded Ruby that uses fully
featured Ruby objects from model
Ruby on Rails
Handles URL parsing, redirection, authentication, and also provides a
“service friendly” interface
Built to the service friendly interface. Returns Ruby objects from database
So We’re Done Right?
The “New” MVC: Model View Mediator
The Old MVC: Model View Controller
THIN
DUMB