Model View Controller

1. Model View Controller A Pattern that Many People Think They Understand, But Has A Couple Meanings

2. 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 pleaseplease keep your model separate. If you do that, your design will be 90% of the way to being good.

3. Smalltalk-80 The very first GUI system. Also one of the first object-oriented languages.

4. A Completely Novel Problem If the right mouse button should be clicked here, what should it do?

5. Hmmm…seems like depends Click! The user is clicking on a variety of different regions. Each reason has a different meaning. 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. 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.

6. An Exciting New Solution: The Controller Updates the view based on input The View: Handles rendering The Controller: Handles input The view gets updates using the observer pattern Updates the model based on input The Model: Handles actual data

7. The Controller Was Actually More Complex Than You Think

8. 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)

9. …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.

10. How Does the Role of the Controller Change? • 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. • 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)

11. 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

12. Model/View/Mediator The “View”: Just a bunch of glued-together widgets from a widget library The Mediator (a.k.a. Controller) : Sets Up and Maintains Relationship Between The View and Model. Often with tons of observers. The Model: Handles actual data

13. So We’re Done Right? The Old MVC: Model View Controller The “New” MVC: Model View Mediator

14. This is potentially a terrible design The “New” MVC: Model View Mediator

15. Two Scenarios You’ve got a banking application. The Model handles details of withdraws, deposits, etc. Consider these two situations: • 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? • 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

16. http://www.sitecrafting.com/blog/model-view-1/ Coupled to both the view and model. Has a tendency to get fat. The “New” MVC: Model View Mediator

17. http://www.sitecrafting.com/blog/model-view-1/ Use lots of fancy design here to keep this extra thin The “New” MVC: Model View Mediator

18. 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 }

19. http://www.sitecrafting.com/blog/model-view-1/ Custom GUI Code, But Still Leaves As Much of the Thinking as Possible to the Model The “New” MVC: Model View Mediator

20. Calendar – Detecting Too Near 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. 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. 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. 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.

21. Model View Coolthing

22. Ruby on Rails Written in HTML/Javascript with embedded Ruby that uses fully featured Ruby objects from model Handles URL parsing, redirection, authentication, and also provides a “service friendly” interface Built to the service friendly interface. Returns Ruby objects from database The “New” MVC: Model View Mediator

23. So We’re Done Right? DUMB THIN The “New” MVC: Model View Mediator The Old MVC: Model View Controller