MVC explained (while waiting for a cheeseburger)

If you have ever been in a software development interview, you have surely been asked about “MVC”. It’s a really common interview question for beginners to semi-senior profiles. Most probably, you have worked (or at least made a personal project) using MVC, but you may not have a formed idea of the concept or know how to explain it. Relax, it’s not that complicated.

Table of contents

Introduction

MVC stands for Separation of Concerns. Well, not really, but mostly. It stands for Model-View-Controller, but it is tightly tied to that concept.

I know there is a lot of articles talking about this, and I’m not going to unveil some reality-changing truth about the concept. The main goal of this post is that, by the time you finish reading it, you have a clear idea of what it is and what it is not.

Two ways of seeing it

As a pattern

It describes a very specific arrangement of the parts of an application:

• View: What the user sees on the screen. It interacts with the controller, not with the model directly. Example: a web app.
• Controller: It’s the mediator between the View and the Model. It makes it possible for them to interact. Example: an API.
• Model: Responsible for storing and persisting application data. Example: a database.

As a concept

It centers around this one concept: Separation of Concerns.

Separation of Concerns is a principle used in programming to separate an application into units, with minimal overlapping between the functions of the individual units.

In essence, the idea is to divide your application into parts, each one handling some concern:

Some parts are going to deal with presentation (displaying data to the user). Some are going to deal with persistence (storing data in a database). Other parts are going to deal with user interaction (figuring out what to do with the requests the user sends).

The original MVC concept is closer to a design pattern and has nothing to do with frameworks.

For example, one could argue that for a big app the MVC arrangement is:

• Model: a database on a server.
• View: a web application developed by the frontend team.
• Controller: an API developed by the backend team.

At the same time, for a small web app, one could say that the arrangement is:

• Model: the Redux store.
• View: a React component (container-component pattern).
• Controller: a React container (container-component pattern).

There is no recipe for how to divide the app, it is different in every case.

Analogy

Imagine your friend Marcus is in a restaurant and he wants to eat something nice. When the waiter arrives to his table, he orders a cheeseburger. Then, the waiter, knowing what Marcus wants, goes over the kitchen and tells the cook to prepare a cheeseburger. The cook, starts working on it. After some time, the cook finishes preparing the food and handles it to the waiter, who finally handles it to Marcus.

Okay, let’s look at this from the developer point of view:

• Marcus is the user, he interacts only with the waiter.
• The waiter is the view, he interacts with Marcus and the cook.
• The cook is the controller, he interacts with the waiter and the ingredients.
• The ingredients are the model, they are what the cook interacts with (and in the end what the user asked for).

Now, some insights:

1. What Marcus wants is a specific combination of ingredients; he doesn’t want each one on a different plate. That is to say, the user doesn’t want raw data from the Model; they want some processed result made out of it.
2. Even if Marcus wanted to stack the ingredients himself, he can’t grab them (he needs the waiter and the cook). That is to say, the user doesn’t have direct access to the Model (he has to go through the View and the Controller).
3. Marcus and the waiter communicate in both directions: Marcus orders something and then, some time after, the waiter gives him what he ordered. That is to say, the user request information then, some time after, the View shows him what was asked.
4. The waiter can’t prepare the cheeseburger, he doesn’t know where the ingredients are or how to make it, he just knows what to say to the cook. The View, like the user, doesn’t have access to the Model, it can only communicate with the Controller.
5. The cook takes each ingredient, then he stacks them, and then he handles it to the waiter. That is to say, the Controller grab information from the Model, processes it, and then handles it to the View.

Conclusion

Understanding MVC is essential for anyone involved in software development, as it is a widely used concept and a common topic in interviews. While MVC stands for Model-View-Controller, it is closely tied to the principle of Separation of Concerns. The pattern of MVC involves dividing an application into three main components: the Model, responsible for storing and persisting data; the View, what the user sees on the screen; and the Controller, the mediator between the View and the Model.

However, it’s important to note that the specific arrangement of these components can vary depending on the application’s size and requirements. MVC is not limited to frameworks and can be implemented differently in different contexts.