Understanding Model-View-Controller (MVC) Architecture

The acronym MVC stands for Model-View-Controller (“Modèle-Vue-Contrôleur” in French) and refers to a software architecture pattern.

If the concept of software architecture is not familiar to you, read our dedicated article: https://code-garage.fr/blog/qu-est-ce-que-architecture-logicielle

As you may have understood, it is an architecture that divides a piece of software, or an application, into three main components: the model, the view, and the controller.

This pattern is used for software with a user interface, but not necessarily a graphical interface (GUI), it is also valid for software running in command lines (CLI).

We could summarize this architecture with a simple diagram like this one:

But let's look together at the theory, the role of each component, and the advantages.

How it works

The model

Your model is where data is manipulated and where storage is managed.

If you have a weather application, for example, the model could contain information about temperature, atmospheric pressure, various user info and their geographic location, etc…

The view

The view represents what users see and what they directly interact with.

If we take the weather application example again, the view would be the user interface displaying forecasts, graphs, etc.

The controller

The controller is like the conductor.

It takes commands from the user through the view, interacts with the model to retrieve or update data, then sends the result back to the view. It's the link between the model and the view.

An analogy

Imagine you run a restaurant.

• The model would be your kitchen, where all the ingredients are stored and prepared, cooked, mixed together, in the right order, etc….
• The view would be the dining room, where your customers see and consume your dishes.
• The controller would be the waiter who takes the customer's order (view), communicates with the kitchen (model), and finally brings the dishes to the table.

It's the same concept with MVC. Each component has a distinct role but works together to provide a complete user experience.

The advantages

Now that we have an idea of what MVC is, let's talk about its advantages. There are 3 main ones, which overlap:

• Separation of concerns: MVC allows for a clear separation of responsibilities. The model manages data, the view manages the user interface, and the controller manages the application logic. This makes the code more readable and easier to maintain.
• Code reuse: By splitting the application into three distinct components, it becomes easier to reuse code. You can change the view without touching the model, or vice versa.
• Ease of testing: Each component can be tested independently. You can test the model's logic without worrying about the user interface, which makes unit testing possible.

Best practices

Thin Controller and Fat Models

In French, “contrôleur maigre et gros modèles”

As explained at the beginning of the article, the MVC model is an architecture pattern, which means it lays the foundation for a structure for communication between each of these elements, but how each component is implemented remains a matter of practice.

One of the best practices in MVC is to reduce as much as possible the pure data processing performed by the controller, and to implement it as much as possible in the various data models.

Example: In our weather application, the user requests the average temperature for a specific day.

The controller could retrieve the data, perform the calculation itself and return the result, but we will prefer to have this calculation directly in the model, and the controller will simply serve to pass the result along to the view.

The business logic will be implemented in the controller, but the data logic will be implemented in the model!

Architecture pattern vs Design pattern

We sometimes read that the MVC model is a design pattern, but this is a distortion of reality.

An architecture pattern gives a higher-level structure, and the underlying implementation can indeed make use of one or more design patterns (e.g. Singleton, State, etc…)

The MVC model is therefore an architecture pattern, and not a design pattern.