MVC and Architectural Patterns

Section 0: Module Objectives or Competencies

Section 1: Architectural Patterns

While design patterns typically focus on components of a subsystem and their relationships and collaborations with each other, architectural patterns focus on the larger subsystems of an application along with their relationships and collaborations with each other.

• The Model-View-Controller (MVC) pattern is probably the most widely known pattern.

Software professionals have embraced patterns as a means of recording and sharing expert knowledge for building software, because experience often makes the difference between being a poor and good designer.

Here is a review page to accompany my notes.

Section 2: Model-View-Controller Pattern

We first encountered the Model-View-Controller Pattern in the OO Design Considerations notes.

Elementary Model View Controller (MVC) by Example.

The Model-View-Controller (MVC) pattern is arguably the best known architectural pattern, and organizes application functionality into three components: (1) models manage application data, (2) views present the user interface, and (3) controllers handle events for views.

• The model is responsible for maintaining the state of the application.
  • This entails both storing data that constitute the application state (e.g., session, database) and handling transactions that affect the state (referred to as application logic or business logic).

• The primary role of the view is to present a user interface for the application.
  • It also passes user actions to the controller for processing, and it obtains presentation data from the model as needed.
  • The model may also push data to the view in response to state changes.
• The controller is the central coordinator for the application.
  • It is responsible for taking user input, interacting with the model, and instructing the view to update and display appropriately.
  • In other words, it handles each user action originating with the view by activating the appropriate model component to handle the transaction, and then selecting the appropriate view component with which to respond to the action.

The figure above illustrates the flow of control and data through the components.

• Each MVC component is connected to the other two through control and data flows.
• A control flow is a pathway for issuing calls or requests, whereas a data flow is a pathway for sending application data.
• View – Controller
  • The view responds to user interactions by notifying the controller of an event and passing along relevant data.
  • Interactions (HTTP requests) can be triggered by a form submission, clicking on a URL, or through AJAX.
  • Some requests will include a data component (e.g., a form submission), whereas others will convey a request only.
  • The controller, in turn, is responsible for setting the view, which could consist of forwarding the request to an existing document or instructing the view component to generate a dynamic document.
• Controller – Model
  • The controller issues transactions based on the requested application function to the model.
  • In the case of an eCommerce site, for example, transactions might include logging in, adding an item to the shopping cart, or entering payment information.
  • The controller uses return values from the model to determine which view to set next.
  • If a user interaction simply requests a change of view, however, the controller may not need to contact the model at all.
• View – Model
  • There are two ways in which this interaction can work.
    • In a data pull relationship, the view requests data from the model.
      • For example, if the controller instructs the view to show a product page, the view will then request product information from the model.
    • In a data push relationship, the model presents updates to the view as they occur.
      • For example, if the view happens to be a weather report, the model might push out weather updates every few minutes to which the view would respond by changing its user display accordingly.

MVC provides separation of concerns, a software engineering principle that states that it is best to segregate different types of functionality within an application as much as possible.

There are several clear advantages to this principle as embodied in the MVC pattern for web applications.

• Simplicity
  • Each component can be designed and developed separately, reducing the overall complexity of the problem.
• Independence
  • Components can be interchanged, replaced, and replicated as needed.
    • The HTML interface to an application, for example, can be replaced or upgraded without affecting other components.
  • Additional views can be developed for other devices, such as mobile phones or terminals for the disabled.
• Scalability
  • Components can be expanded with additional capabilities.
  • Additional views and models can be added to an existing application.
• Specialization
  • Developers can specialize on one component, and can fine-tune their skills in that area.

References

• MVC Architecture in 5 minutes: a tutorial for beginners
• JavaScript MVC

Section 3: Resources

Internationally acclaimed paper on design patterns, frameworks, and MVC

What is MVC?

Introducing The MVC Model View Controller Pattern

Understanding the Model View Controller coding pattern (now private on YouTube)

Using the Model View Controller MVC pattern (no YouTube link)