MVC (Model-View-Controller) is one of the most popular architectural patterns, used to organize the structure of an application by separating different responsibilities into three main components: Model, View, and Controller. MVC reduces dependencies between components and makes our applications easier to develop, test, and maintain. In this article, we will explore the MVC pattern together!

What is MVC?

MVC stands for:

• M – Model
• V – View
• C – Controller

The main idea of ​​MVC is the separation of responsibilities within an application.

Instead of having a single component handle everything such as:

• Receiving user input
• Processing data
• Executing business logic
• Managing state
• Displaying results

MVC divides these responsibilities into separate components:

• Model – manages the application’s state and data
• View – responsible for displaying information
• Controller – handles interaction and coordinates between the user, Model, and View

MVC workflow

For example, in a banking application workflow, when a user requests to deposit $500 into their account, the Controller receives this request and manages the processing. The Model updates the application’s state; for instance, if the user’s current balance is $1000 and they deposit an additional $500, the new balance will be $1500. The View uses the user’s new state to display the balance as $1500.

Model

The Model represents the application’s state and data.

The Model can contain information the application needs to perform its operations.

For example, imagine we are building a banking application.

An Account might have:

For example:

This is a part of the application state that a Model can represent.

A Model doesn’t necessarily have to be a single class.

For example, an application might have:

All of these objects can be part of a Model depending on how the application is designed.

A Model doesn’t necessarily have to be a Database Entity or a DTO!

View

A View is responsible for presenting or displaying information to the user.

For example, in a banking application, a View might display:

The View focuses on how information is presented.

Controller

The Controller is responsible for handling interactions and coordinating the processing.

For example, the user performs the following action:

The Controller can receive this interaction and request the Model to update the state.

The original MVC pattern

The MVC pattern was first introduced by Trygve Reenskaug while working on the Smalltalk project at Xerox PARC (a company in California, USA) in the 1970s. At that time, this pattern was applied to desktop applications.

The original MVC pattern divides the presentation layers into different components. Each component takes on a different role, as I shared above:

• The View uses the Model to display results to the user.
• Based on the user’s action, the View triggers the Controller to process the user’s operation.
• Then, the Controller updates the data for the Model.
• When the Model’s state changes, the View can be updated to reflect this new state.

This model works very well with desktop applications, but applying it to web applications is not feasible due to the nature of the HTTP protocol in web applications being request/response.

In a web application, the user interacts with the application by sending a request to the server running that web application. The web application processes this request, updates the interface, and then sends it back to the user. This means we need a different way of handling things in the web environment; instead of pushing changes to the View, these changes are retrieved from the server.

That’s why we need to make changes to the MVC pattern for the web environment.

MVC pattern in the web environment

To overcome the difficulties of the MVC pattern in the web environment, a common method is to use the Front Controller Pattern.

Simply put, the Front Controller is the first place to receive requests from the user and it is also the place that returns the results to the user. Instead of each request being sent directly to a separate Controller, the request first goes through the Front Controller. The Front Controller can then determine which Controller is appropriate to handle the request. These Controllers will process the request, return the model, and select the view to use.

Please see the following diagram:

Spring MVC implements the Web MVC architecture by using DispatcherServlet as the front controller.

DispatcherServlet provides a general request processing workflow and delegates specific tasks to other Spring MVC components.

Some tasks delegated by Spring MVC include:

• Finding the appropriate Controller for the request.
• Invoke the Controller.
• Handle the Model and View.
• Resolve the View.
• Handle exceptions.
• Convert Java objects into HTTP responses.

Summary

MVC is a pattern that separates responsibilities in an application into three main groups: Model, View, and Controller.

When applying MVC to a web application, the HTTP request/response model changes how these components interact. A common solution we can use is the Front Controller Pattern.

Different Java frameworks may have different implementations of the MVC pattern, but their underlying ideas are all based on this MVC pattern!