How MVC works ?

The post is originally written here -> www.easyontheweb.com

If you have started learning or have been in web development for some time I’m sure you must have heard of the term ‘MVC’. It’s natural to hear such a term and get a question in your mind that “What is MVC” ? So, in this article we’ll be exploring what MVC is and how MVC works .

What you might be knowing is that MVC stands for Model-View-Controller and that it is an architectural pattern used in designing applications. In this article we’ll also explore why people use MVC so extensively and what would make it a great choice for your next application.

What is MVC ?
Let us begin with the very first question that needs to be answered – what is MVC ? As told before MVC stands for Model-View-Controller and it’s an architectural pattern in which we organise our applications.

This architectural pattern focuses mainly on separation of concerns and has been designed to keep different parts of the application in different parts of your codebase. We will go into deep about what each of the model, view and controllers are later in the article but for now you need to think of them as different parts of a well oiled machine that work in a defined manner with each other to make our applications run.

Even while writing the previous paragraph I felt the explanation wasn’t clear enough so let me just dive a little bit into each one of them and give you a basic overview about the MVC architecture.

So, the MVC architecture consists of three parts – Model (handles data related actions), View (handles UI related stuff) and Controller (acts as an intermediary between both of them). These three parts together are responsible in the processing of a request from the browser (controller), getting the appropriate data for that request (model) and showing the data back to the user (Views).

In MVC, we structure our applications in such a way that all these three parts are solely responsible for their part of the jobs and they do not intermingle with each other’s works.

This keeps the application clean, the codebase separated and in general just easier to manage huge applications as such.

Who uses MVC ?
I personally began my web development with Ruby On Rails and Rails used MVC by default and that is when I was exposed to this idea of models, views and controllers. Rails’ sibling Sinatra also uses the MVC architecture and there are a lot of other frameworks which use MVC in different ways even though the underlying concept behind them is more or less the same.

We might find a couple of differences in how different frameworks implement MVC but in this article we’ll just be taking a generalised look over things. Nevertheless, some of the most famous frameworks that use MVC architecture are :-

Ruby On Rails
Sinatra
Angular
Laravel
Django
Flask
As you can see the list ranges from Ruby to Javascript to Python and many others actually. There are a lot of advantages of using the MVC architecture and we’ll go through them as well. First , let us take a look at what models , views and controllers are individually.

Controllers
We start with controllers instead of models because that is actually where we start when it comes to the working of MVC.

Controller is the part of your code where we handle requests issued by the users on the browser or the terminal or wherever else he is hitting the endpoint from.

Whenever the user makes an API request to our application it is first taken by the router which then forwards it to a certain function written in a certain controller. Say, the request is to get all the posts in your application and the endpoint for that request is /posts/fetchAll . This route would be declared in our router file and this route would’ve been bound to a certain action in a controller. In our case, we’ll say that when this API is called we want the PostsController.fetchAll function to run.

Our router in a way then asks the PostsController to take up this request and process it using it’s fetchAll function. The syntax of binding a route to a controller function varies from framework to framework but the concept is the same – each route is bound to a controller function.

That controller function is then responsible to process the request, apply some logic on it (often communicate with appropriate model) and then return a response back. So, you can think of controllers to be modules that contain functions that are bound to certain API routes in our applications. These functions are responsible for handling requests and returning the appropriate responses.

Models
Then to the next part. As I mentioned in the controllers section that the controller has to process the request some way – the request we had taken up for example was fetching all the posts. So, in this case the controller actually wants a list of all the posts in the application so that it can return it as a response to the request.

Naturally, the posts would be stored in a database (or wherever you want to, maybe you write data to files for some reason). So, what would happen is that your postsController would ask it’s appropriate model (most probably named Post) for the list of posts. The model would then make a query to the database or file or wherever it has to read the data from and return the data back to the controller which will return it as response.

So, the model is the part of the application that concerns itself with data fetching, storage and manipulation. Many a times you would use some ORM/ODM layer in your models to access the database but that is an entirely different concept altogether. For now, you need to know that models code is what would work with data in our application, that’s it.

So, at the end of the processing in the model, the model returns the data to the controller (in very rare circumstances in certain frameworks, it can even render the view itself but just ignore that) which then renders the V of the MVC.

Views
The final part of the MVC trio is the view part , which is the part that controls what is to be rendered on the browser or application or whatever has to be shown to the user.

As mentioned before the controller gives the appropriate response to the views of our application and the view part decides how and what to render from the response it has received from the controller.

Also, just to be clear here – the view in the MVC could be anything – maybe a templating engine like erb or pug or whatever or maybe a complete library like React or Vue. The way you handle your views rendering is upto you as long as they just fit into the MVC architecture and follow the same flow of data.

image source: python planet
Advantages of using MVC
Finally to the part where we discuss why you should use the MVC architecture in your applications and why it has grown in popularity so much so that all the leading frameworks follow it.

The advantages of using the MVC architecture are as follows :-

Separation of concerns – Different parts of your application are separated in the code as well as the working which leads to easier development.
Less coupling – Another thing you could do is say, use two different views depending on different conditions. As the view code is completely separated from the other two parts, you can easily do that.
Easier maintainability – One thing that MVC does bring to the table is easier maintainability of the project as you know where you need to check in case of a bug.
Easier to scale – Another thing with MVC apps is that it is easier to scale them in terms of the codebase without worrying about spaghettis.
I hope this article gave you somewhat of an understanding of the MVC architectural pattern and you will try it in your next application if you do not work with it right now. It’s great and I personally follow it like on all the applications.

If you want to become a MERN stack dev then I have 5 of the most awesome resources compiled for you here, do check them out -> https://easyontheweb.com/5-resources-to-become-a-mern-stack-developer/