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