Model View Controller Design Pattern

The model view controller is a software pattern that is used for web development services such as applications; irrespective of the language. It is one of the most widely used paradigms in web development. Model represents the information (the data) of the application and the business rules used to manipulate the data, the View corresponds to elements of the user interface such as text, checkbox items, and so forth, and the Controller manages details involving the communication between the model and view. The controller handles user actions such as keystrokes and mouse movements and pipes them into the model or view as required. Basically, it says that there are three distinct responsibilities for our application i.e.

1. Model
   • Manages the app data and state
   • Not concerned with UI or presentation
   • Often persists somewhere
   • Same model should be reusable, unchanged in different interfaces
2. View
   • Present the Model to the user in an appropriate interface
   • Allows user to manipulate data
   • Does not store any data except to cache state
   • Easily reusable & configurable to display different data
3. Controller
   • Intermediary between Model & View
   • Updates the view when the model changes
   • Updates the model when the user manipulates the view
   • Typically where the app logic lives

This pattern decouples changes to how data are manipulated from how they are displayed or stored, while unifying the code in each component. In other words, it’s a way of developing apps keeping the data (model) used in the program, and the visual (view) component of the program separate from one another, each interacting only with a controller containing the logic of our program. The view and the model interact only with the controller NEVER with each other.

Here is a diagram that shows the MVC pattern in action:

Example

Let’s take an example of an online stationery shop. The user can view items, buy, add items to cart, add items to current order, or even add/remove items. Now, let’s see what will happen when a user clicks on the title “Pens” to see the list of pens.

Application will have a controller to handle all the queries related to pens. We’ll also have a model that will store the data regarding the pens we have. Finally, we’ll have several views to present the data – a list of pens, a table displaying pens, a page to edit the list, etc. The following figure shows the complete flow of control right from the moment a user clicks on “pens”, to when the result is rendered in front of him:

First, the controller handles the user request (1) as a GET or POST request. The controller then examines the request and the parameters and calls the required model . The controller asks the model to return the list of available pens (2). Now, the model searches the database for the necessary information (3), applies logics if necessary, and returns the data to the controller(4).
The controller then picks an appropriate view (5) and presents the data (6 and 7).