As software grows, its parts can become tangled, making it hard to know where to make a change. When user interface code and data processing logic are mixed together, a small edit can have wide effects.
The
ModelโViewโController (MVC) pattern
gives each part of an application one of three roles. The parts work together while limiting how much a change to one affects the others. Think of an organized kitchen where cooking, serving, and washing dishes are separate jobs. MVC can make software easier to build and maintain in much the same way.
It stores, retrieves, updates, and validates data. When data changes, it can notify interested components, typically views. It concentrates on data and the rules that govern it, leaving display and input handling to other parts of the application.
It presents data from the model and receives user interactions, such as button clicks and text input. It focuses on presenting information, leaving data storage and processing to the model.
It receives input, usually through the view, interprets it, and asks the model to perform the appropriate operation. It can pass the result to the view and direct it to update. The controller manages the overall application flow.
๐จโ๐ป
The three components depend on one another to work, but their distinct roles help limit the effect of changes.
Here's a common sequence of messages between the components.
Diagram showing how MVC components interact
The user provides input
The user interacts with the view, for example by clicking a button or entering text on a web page.
The view forwards an event to the controller
The view detects the action and forwards it. The controller determines how to handle the event.
The controller requests an operation from the model
The controller interprets the request and asks the model to update data or run business logic, such as saving a new post or retrieving the product list.
The model processes data and updates its state
The model carries out the request and changes its state if needed. It may access a database or perform calculations.
The model optionally notifies the view
When its state changes, the model can notify views that observe it, for example through the Observer pattern. The controller can also handle this step.
The controller directs an update, or the view reads the model
After receiving the result or detecting the model change, the controller determines which view should refresh. The view can read the data directly from the model, or the controller can pass it along.
The view updates the screen
The view gets the latest data from the model or controller and shows the changes to the user.
Each component can focus on its own responsibility.
In this widely used Java web framework, DispatcherServlet acts as the front controller. Classes annotated with @Controller handle requests and provide model data to views such as JSP or Thymeleaf.
Ruby on Rails (Ruby)
Rails supports MVC through its convention-over-configuration approach. Active Record handles models, Action View handles views, and Action Controller handles controllers.
Django (Python)
Django's ModelโViewโTemplate (MVT) terminology describes a similar approach. The Django view handles requests in a controller-like role, and the template handles presentation.
Express.js (Node.js/JavaScript)
Express is a flexible middleware framework in which developers can organize their own MVC structure.
MVC helps you structure an application by assigning clear responsibilities to models, views, and controllers. This can make code more flexible, easier to extend, and easier to maintain.
The project's size and needs determine whether and how to apply MVC. The underlying idea of
separating concerns
is worth keeping in mind regardless of what you build.
Next time, we'll look at how to define and document software requirements clearly in a