The Model-View-Controller Architecture

							The Model-View-Controller
      Architecture
       Model-View-Controller
• Architecture for interactive apps
   – introduced by Smalltalk developers at PARC
• Partitions application so that it is
   – scalable
   – maintainable
                       View
      Model
                    Controller
                          Model

                                View
              Model
                             Controller

• Information the application is manipulating
• Data representation of “real” world objects
   – “circuit” for a CAD program
      • logic gates and wires connecting them
   – shapes in a drawing program
      • geometry and color
   – database
                   View
                     View
          Model

                    Controller

• Implements visual display of model
• May have multiple views
  – e.g., shape view and numerical view
• When model is changed notify views
  – so view can change later (e.g., adding new item)
                  Controller

                       View
          Model
                     Controller




• Receives all input events from user
• Decides what they mean & what to do
    Controller Communication
                          View
            Model
                        Controller


• Communicates with view
  – determines which objects are being manipulated
    • e.g., which object was selected with mouse click
• Calls model methods to make changes
  – model makes change and notifies views to update
      Relationship of View &
             Controller
“pattern of behavior in response to user events
  (controller issues) is independent of visual
  geometry (view issues)”

->Controller must contact view to interpret
  what user events mean (e.g., selection)
Combining View & Controller
• View & controller tightly intertwined
   – lots of communication between the two
• Almost always occur in pairs
   – i.e., for each view need a separate controller
• Many architectures combine in 1 class



                          View
           Model
                        Controller
                   Why MVC?
• Combining MVC into one class or using global
  variables will not scale. Why?
  – model may have more than one view
     • each different & needing update on model changes
• Separation eases maintenance. Why?
  – easy to add a new view later
     • may need new model info, but old views still work
  – can change a view later
     • e.g., draw shapes in 3-d
         – recall that the view handles selection
            MVC on the Web
•   Latency and Bandwidth
•   Granularity of control
•   Granularity of messages
•   Scalability
•   Concurrency
•   Security
               MVC on the Web
                                      All interaction with
Model-view interaction means          the user is done
       DB code in view                with the view
       view code in model
Switch to Model-Controller


                               View
         Model
                         Controller
       Other Architecture Issues
•   Single point of entry
•   Data Driven Design
•   Verifying User Input
•   Handling Forgotten Passwords
•   Cookies and login
        Single point of entry
• Often we want users to see one place to
  enter our site.
• Single JSP or servlet
  – Determine session state
  – Forward to appropriate page
• Multiple form actions depending on input
          Servlet Forwarding
• Traditional forms only have a single point
  of contact for action.
  – <form action=“URL”>
• What if we want to separate things a bit
  more depending on input data?
  – Multiple form tags
  – Big servlet acting based on passed data
  – Servlet forwarding
              Servlet forwarding
public void doGet(…)…
{
         String op = request.getParameter(“operation”);
         if (operation == null)
                   gotoPage(“URL1”, request, response);
         else if (operation.equals(“op1”))
                   gotoPage(“URL2”,request, response);
}
private void gotoPage(Sting URL, HttpServletRequest request,
                                     HttpServletResponse response)
                   throws ServletException, IOException
{
         RequestDispatcher dispatcher =
                   getServletContext().getRequestDispatcher(URL);
         dispatcher.forward(request, response);
}
       Sending information to
          forwarded page
• Use beans
  – Session scope
  – Available to page
• What about the relative URLs used
  – Interpret them
         Data Driven Design
• As you design your site, focus on the data
  – Get the data
  – Put it in a bean
  – Transfer to appropriate page that will do
    transformations on the data.
• Track the data all the way through
  – Data Flow Diagrams
           Verifying User Input
• Javascript is helpful
• Verify as you put it into bean
• Error Handling
   – Error Vector Bean
   – As errors happen, put them in vector
   – Forward right back to current page
      • Page always displays errors
• Errors are best noted near the field where the error
  occurred.
            Cookies and Login
• Users hate logging in.
• Web sites often store login info in cookie
  – Hacking possibility
• Suggestions
  –   Don’t make cookies easy to guess
  –   No plaintext in cookie
  –   Uniquifiers and frequent cookie replacement
  –   Be careful about your cookie paths
  Handling Forgotten Passwords
• User Information should contain a secure
  email address.
• Email password to address
• This assumes that if user has lost control of
  email, they have more serious problems
  than a forgotten password.
• Java Mail API