For anyone who’s developing a web application, figuring out how to structure the different modules of the app is a fundamental point to consider. One methodology or design pattern widely used is the model-view-controller (MVC) structure. It determines how the user interface interacts with the underlying data models.
In this post, I’ll give a simple explanation about how the model-view-controller (MVC) pattern works. Since the concept might sound rather abstract if you’re new to programming or developing web apps, I’ll use a very simplified example from everyday life to help you grasp the idea.
If you’re not familiar with how web applications work, check out my previous post on the topic.
What is the model-view-controller (MVC) pattern?
Now there are plenty of differing views about what an MVC is exactly or how the entire subject is to be understood. In fact, people can be quite passionate about interpreting it in a certain way. Obviously there’s not just one single way of explaining and interpreting the pattern.
In case you have another example or view about the MVC that would be helpful for understanding what it’s all about, please feel free to share it in the comments below!
All that matters is that you understand that there are different interconnected parts in it and they have their separate jobs. That should get you well on your way towards grasping what the MVC is all about.
The MVC is basically a model used as a pattern for developing desktop applications and web apps. It applies to several different programming languages and web app frameworks, like Python and Django or Ruby and Rails, for instance. However, the separate modules might have different names and terminology across the different frameworks.
MVC separates logic from interface
No matter which framework you’re using, the fundamental idea behind the MVC is that it separates the application’s logic from its interface. So the actual functionalities are kept in one pot, while the visual, interactive user interface sits in its own pot.
But what’s the point of such a structure?
The biggest benefit of this separation is that you could have two separate teams working on an application at the same time. Back-end developers would focus on the server side while front-end developers work on the user interface.
Based on this idea of separating the different modules, the model-view-controller pattern divides an application into three interconnected parts.
Let’s take a closer look at each one of them:
1: The Model
The model is the smart part. It knows how to handle the data stored in the application and how to respond to requests for information, for instance.
In other words, the model is the brain of the app. The other two parts don’t know how to manipulate and process data stored in the application.
On the other hand, the model never tells the other two what to do. It doesn’t know anything about how the other two parts work (remember, the parts are interconnected but separate).
2: The View
The view is the pretty part. It doesn’t really know much about how things are done, so it’s not too bright. It simply presents data from the model to the user in an appropriate form.
Most importantly, the view is designed to interact with the user. So no matter which application we’re talking about, the view (or the interface) needs to be easy to use. That’s what the view is all about. Less is more!
3: The Controller
The controller is the bossy manager. It stands between the model and the view, coordinating the entire show.
Whenever the controller receives a request from the user (either directly or via the view), it puts the model to work. And when the model delivers the data requested in the right format, the controller forwards it to the view.
So in other words, the controller pushes instructions to the model and pulls information from it. Moreover, this information is in the appropriate form for the view to present it to the user. (Remember, the view isn’t too clever!)
Still with me?
Now the entire concept of the model-view-controller approach might seem a bit abstract if you’re completely new to it.
To give you a better idea of what’s really going on, let’s look at a more practical example.
Simple MVC example: buying ice cream
…because everyone loves ice cream!
So, let’s assume it’s a hot day and you go to your favourite gelato spot. But what does it have to do with the model-view-controller?
Consider the following workflow at the ice cream shop, using the three separate MVC parts we just talked about:
1: Request from user to controller
First off, you go to the person running the place and order a banana split (request).
They greet you with a smile, take your order, and tell you to take a seat. Since the owner is in charge (controller), they give your order to the employee responsible for preparing the dish.
2: Controller puts model to work
The employee (model) knows exactly how to prepare a tasty banana split. You know, which flavours to use, how to properly cut the banana in half and which sprinkles to decorate the entire thing with. So the employee gets to work and before long, they’re done!
3: Model delivers output to view via controller
After that, the employee hands the dish to the owner (controller). The owner then tells the waiter (view) to bring the tray to you. And there you have it, a delicious dessert exactly how you wanted it.
So let’s review the individual steps:
- First, the user gives a request to the controller.
- The controller tells the model what to do.
- The model then retrieves all the necessary data from the database.
- Then, the model hands this data over to the controller in the correct form.
- Next, the controller hands the whole thing to the view.
- And finally, the view presents it to the user.
Of course, at the gelato place it can take a while before you receive your order after all these steps. But when it comes to web apps, all this happens in the blink of an eye. That is, when everything is running smoothly!
And also, the database in the example consists of ice cream flavours, fruit, and sprinkles. In real life, a web app stores all sorts of data from its users. Every click, every like, every comment, every message you ever sent – the amount of information and data out there about you and me is incredible!
Furthermore, keep in mind here that the view also interacts with the user, especially in web applications. Hence, the request doesn’t necessarily go directly from the user to the controller. The view is the user interface in that case, i.e. the browser where the user sends requests to the controller. At the gelato place, you could for example place a new order with the waiter. They would then pass it on the controller.
Final thoughts: How does the Model-View-Controller pattern work?
The model-view-controller (MVC) design pattern is a common concept in application development, for both desktop and web applications. However, the entire idea might seem a bit abstract at first. That’s why I thought a practical example could help you understand it more easily.
Understanding the MVC pattern is crucial before you start developing your own apps, or at least extremely helpful. It helps you keep the logic of the application separate from its interface.
That way, you can keep all functionalities separate from each other. This allows you to tweak them individually without breaking your beautiful app accidentally.
As I mentioned before, there are lots of different views about what the MVC is all about and how it should be interpreted. My example and interpretation are just one way to view the entire thing.
That said, please share your thoughts and ideas in the comments below or send me a message!