Model View Controller – MVC

The Model View Controller (MVC) approach is a software design pattern commonly used for developing user interfaces that divide the related program logic into three interconnected elements. This is done to separate internal representations of information from the ways information is presented to and accepted by the user.  

MVC splits program functions into three pieces:

• data that means something (the Model),
• the way that data can be shown to a user (the View), and
• the operations the user may apply to the data (the Controller).  

Instead of mixing these three functions into one set of programming code, developers separate them into their own “boxes” and define how they interact.

This results in much better flexibility, for example, for showing the same data on different devices, like web browsers on PCs and an app on the phone. It is the same data but presented in a separate “view” module. 

Extra Background

To dig deeper into how MVC works, let’s break down the responsibilities of each component.  

The Model is responsible for the data and the rules for manipulating that data. Models are often designed to work with databases; they retrieve, manipulate, and store data in the database. They act as a data gateway for the application.  

The View is where the data from the model is presented. The view doesn’t know where the data comes from; it just knows it’s tasked with rendering it. A single model can have multiple views. For example, one view could be a bar chart for data analysts, while another could be a tabular display for general users.  

The Controller is the glue that connects the model and view. It’s tasked with receiving user input, usually from interactions with the view, and deciding what to do with it. It might mean asking the model to update its data or telling the view to change in some way.  

In other words, each component in the MVC architecture is designed to handle specific development aspects of an application.

It is the foundational structure behind most web applications because it provides a clean separation of concerns. It also makes it easier to maintain, scale, and test applications.

A Practical MVC Example

Having a different purpose for each of these three pieces of software makes it much easier to enhance and expand their functions.

For example, suppose software for flight information is using the MVC approach. In that case, showing flight information to passengers in an app is all about creating a new “view” compared to the presentation of this information in a browser session.  

Similarly, if the software designer wants to add “luggage information” to the functionality, the Model part would be updated to include data about the passenger’s luggage, such as the number of bags, bag tag ID code, the status of where the bag is, etc.  

Such changes to the Model can be done entirely independently from the View and the Controller. The View component can then be expanded also to present luggage information. The Controller can be expanded to include support functions such as a “where is my luggage” button that the user can click.   

When activated, the Controller asks this question of the Model, which looks up in the database “where the luggage bag tag was last scanned” and what that location is called, which could be a flight number and loading status, such as “loaded on flight 987”.  

When the Controller makes this request, the Model gets the answer, and then the Controller passes the response to the View function. Depending on the specific interface on which the View function is presenting the information, the format is adjusted in terms of font, letter size, color, etc.  

Again, the key point is that these three functions are separated in the MVC approach so that each can be maintained much more efficiently compared to the complexity of keeping all the different options mixed into one overall program that deals with all scenarios. 

History of the Model View Controller Approach

The Model-View-Controller (MVC) design pattern has a long history. It was first introduced in the late 1970s by Trygve Reenskaug, a Norwegian computer scientist, while working on Smalltalk-80 at Xerox PARC.

Smalltalk is an object-oriented, dynamically typed, reflective programming language that influenced many modern programming languages like Ruby and Python.

The idea behind MVC was to separate the representation of information from the user’s interaction with it.  

MVC Use Cases

The MVC design pattern is prevalent in web development, and many widely used frameworks are built upon it, such as Ruby on Rails, Django (Python), and ASP.NET MVC. It’s well-suited for web applications where the user interface and the underlying data often change independently and for different reasons.  

For example, the user interface could change because of a design refresh, while the data could change because of new business requirements. MVC can make these changes independently without affecting the other components.  

Conclusion

The primary benefit of the MVC pattern is the separation of concerns, which leads to a more manageable and modular codebase.

By keeping the three concerns (data, user interface, and control logic) separate, developers can work on one aspect of the application without needing to understand the other two.

This separation also makes the code more reusable and easier to test, leading to more robust and maintainable applications.  

MVC Explained in 4 minutes