My Books‎ > ‎Software Engineering‎ > ‎

MVC-Model-View-Controller-Architecture

Problem

Enterprise applications need to support multiple types of users with multiple types of interfaces. For example, an online store may require an HTML front for Web customers, a WML front for wireless customers, a JavaTM (JFC) / Swing interface for administrators, and an XML-based Web service for suppliers. When developing an application to support a single type of client, it is sometimes beneficial to interweave data access and business rules logic with interface-specific logic for presentation and control. Such an approach, however, is inadequate when applied to enterprise systems that need to support multiple types of clients. Different applications need to be developed, one to support each type of client interface. Non-interface-specific code is duplicated in each application, resulting in duplicate efforts in implementation (often of the copy-and-paste variety), as well as testing and maintenance. The task of determining what to duplicate is expensive in itself, since interface-specific and non-interface-specific code are intertwined. The duplication efforts are inevitably imperfect. Slowly, but surely, applications that are supposed to provide the same core functionality evolve into different systems.

     

     

     



Solution

The Model-View-Controller (MVC) architecture separates core business model functionality from the presentation and control logic that uses this functionality. Such separation allows multiple views to share the same enterprise data model, which makes supporting multiple clients easier to implement, test, and maintain.

Structure

Participants & Responsibilities


    Model

    The model represents enterprise data and the business rules that govern access to and updates of this data. Often the model serves as a software approximation to a real-world process, so simple real-world modeling techniques apply when defining the model.

    View

    The view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes. This can be achieved by using two models: push and pull.

     

    Pull

    the view is responsible for calling the model when it needs to retrieve the most current data

    Push

    the view registers itself with the model for change notifications

     

    Controller

    The controller translates interactions with the view into actions to be performed by the model. In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in a Web application, they appear as GET and POST HTTP requests. The actions performed by the model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.

History

     

    The pattern was first described in 1979[1] by Trygve Reenskaug, then working on Smalltalk at Xerox PARC. The original implementation is described in depth in the influential paper Applications Programming in Smalltalk-80: How to use Model-View-Controller.[2]

    After that, numerous derivatives of the MVC pattern appeared. Probably one of the most known of them is the Model View Presenter pattern, which appeared in the early 90s and was designed to be an evolution of MVC. However Model-View-Controller still remains very widely used.

     

    In November of 2002 the W3C voted to make MVC structures part of their XForms architecture for all future web applications [3] . These specifications will now be integrated directly into the XHTML 2.0 specifications. There are now over 20 vendors that support XForms frameworks with MVC integrated into the application stack.

     

    Dual Role as Architectural and Design Pattern

     

    Pattern

    Description

    Architectural

      It is common to split an application into separate layers that run on different computers:

    1. presentation (UI)
    2. domain logic
    3. data access
    4.  

      In MVC the presentation layer is further separated into view and controller.

       

      MVC is often seen in web applications.

       

      Web Application Presentation Layer

      Description

      View

      HTML page

      Controller

      code that gathers dynamic data and generates the content within the HTML

      Model

      actual content, usually stored in a database or in XML nodes, and the business rules that transform that content based on user actions

       

      Though MVC comes in different flavors, control flow generally works as follows:

    5. The user interacts with the user interface in some way (e.g. presses a button).
    6. A controller handles the input event from the user interface, often via a registered handler or callback.
    7. The controller notifies the model of the user action, possibly resulting in a change in the model's state. (e.g. controller updates user's Shopping cart).[4]
    8.  

      A view uses the model (indirectly) to generate an appropriate user interface (e.g. the view produces a screen listing the shopping cart contents). The view gets its own data from the model. The model has no direct knowledge of the view.

      The user interface waits for further user interactions, which begins then a new cycle.

      Some implementations such as the W3C XForms also use the concept of a dependency graph to automate the updating of views when data in the model changes.  By decoupling models and views, MVC helps to reduce the complexity in architectural design, and to increase flexibility and reuse.

    Design

    Layer

    Description

    Model

    The domain-specific representation of the information on which the application operates. Domain logic adds meaning to raw data (e.g., calculating whether today is the user's birthday, or the totals, taxes, and shipping charges for shopping cart items). Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model.

    View

    Renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes.

    Controller

    Processes and responds to events, typically user actions, and may invoke changes on the model.

     

GUI Frameworks and Web Development Frameworks

     

    Framework

    Model Part

    Description

    GUI

    Swing

    Summary

    Java Swing is different from the other frameworks, in that it supports two MVC patterns.

     

    Model

    Frame level model-- Like other frameworks, the design of the real model is usually left to the developer.

    Control level model-- Swing also supports models on the level of controls (elements of the graphical user interface). Unlike other frameworks, Swing exposes the internal storage of each control as a model.

     

    View

    The view is represented by a class that inherits from Component.

     

    Controller

    Java Swing doesn't necessarily use a single controller. Because its event model is based on interfaces, it is common to create an anonymous action class for each event. In fact, the real controller is in a separate thread (the Event dispatching thread). It catches and propagates the events to the view and model.

    Combined - JEE Simple Version

    Summary

    Simple Version using just Servlets and JSPs from J2EE.  The simple version uses the best parts of Servlet and JSP technology.

     

    J2EE Component

    Description

    Servlet

    essentially a Java class and communicates and interacts with the model but does not have to do extensive generation of xhtml output

    JSPs

    do not have to communicate with the model as they are provided with the information they need by the servlet they can concentrate on creating xhtml output.

     

     

    Model

    The model is a collection of java classes that together do something useful - they make up a software application which might involve moving data around. There is a single front end class that can communicate with any UI - eg a console, a thick GUI or a web application.

     

    View

    The view is represented by Java Server Page, with data being transported to the page in the HttpServletRequest or HttpSession

     

    Controller

    The controller servlet communicates with the front end of the model and loads the HttpServletRequest or HttpSession with appropriate data, before forwarding the HttpServletRequest and Response to the JSP using a RequestDispatcher.

    Combined -  JEE

    Summary

    Unlike the other frameworks, Java EE defines a pattern for model objects.

     

    Model

    The model is commonly represented by entity beans, although the model can be created by a servlet using a business object framework such as Spring.

     

    View

    The view in a Java EE application may be represented by a Java Server Page, which may be currently implemented using JavaServer Faces Technology (JSF). Alternatively, the code to generate the view may be part of a servlet.

     

    Controller

    The controller in a Java EE application may be represented by a servlet, which may be currently implemented using JavaServer Faces (JSF).

    Xforms

    Summary

    XForms is an XML format for the specification of a data processing model for XML data and user interface(s) for the XML data, such as web forms.

     

    Model

    XForms stores the Model as XML elements in the browser. They are usually placed in the non-visible <head> elements of a web page.

     

    View

    The Views are XForms controls for screen elements and can be placed directly in the visible section of web page. They are usually places in the <body> elements of a web page.

    The model and views are bound together using reference or binding statements. These binding statements are used by the XForms dependency graph to ensure that the correct views are updated when data in the model changes. This means that forms developers do not need to be able to understand either the push or pull models of even processing.

     

    Controller

    All mouse events are processed by XForms controls and XML events are dispatched.

     

Implementations of MVC as web-based frameworks

     

    In the design of web applications, MVC is implemented by web template systems as "View for web" component.

     

    MVC is typically implemented as a "Model 2" architecture in Sun parlance. Model2 focuses on efficiently handling and dispatching full page form posts and reconstructing the full page via a front controller. Complex web applications continue to be more difficult to design than traditional applications because of this "full page" effect. More recently AJAX driven frameworks that focus on firing focused UI events at specific UI Components on the page are emerging. This is causing MVC to be revisited for web application development using traditional desktop programming techniques.

     

     

    Technology

    MVC Framework

    .NET

    1. ASP.NET MVC Framework

     

    1. Maverick.NET

     

    1. Monorail An ActionPack inspired MVC framework from the Castle Project

     

    1. ProMesh.NET Open source MVC Web Application Framework for .NET 2.0 or higher.

     

    1. PureMVC Framework for C#

    ColdFusion

    1. Mach-II A framework that focuses on trying to ease software development and maintenance

     

    1. Model-Glue Through a simple implementation of Implicit Invocation and Model-View-Controller, they allow applications to be well organized without sacrificing flexibility.

     

    1. FuseBox Fusebox does not force the Model-View-Controller (MVC) pattern or Object-Oriented Programming (OOP) on the developer. However, either or both of these development approaches can be used with Fusebox.

     

    1. PureMVC Framework for ColdFusion

    Java

    1. Aranea

     

    1. Cocoon

     

    1. Grails

     

    1. Google Web Toolkit

     

    1. Oracle Application Framework

     

    1. Spring MVC Framework

     

    1. Struts

     

    1. Stripes

     

    1. Tapestry

     

    1. WebObjects

     

    1. WebWork

     

    1. Wicket

     

    1. JSF

     

    1. PureMVC Framework for Java

    Javascript

     

    ABAP

     

    Informix

     

    Perl

     

    PHP

     

    Python

    DJango

    Ruby

    Rails

    Smaltalk

     

    XML