For entry-level, web development enthusiasts and beginners alike, understanding the Model View Controller architecture can at times be a daunting task. In a variety of cases, its usage and implementation in projects may be discouraging when getting your feet wet in the early stages.
In this article, I have tried to explain the basics of the MVC concept. The concept can be implemented differently in other types of programming. My explanation is, however, pegged on a web development point of view. Also, as a result, the illustrations won’t touch on any specific language as I try to map out how everything connects.
A normal web application can have many moving components working together as a unit, for the application to work. The Model View Controller architecture is more often than not, a part of these moving components in the application.
MVC is one of the most frequently used industry-standard concepts in creating scalable and extensible projects. It does this by separating application functionality inside of projects.
An analogy of what all this is all about can be explained using a user interacting with a website.
A user initiates a process with a click to view a certain page. The web application takes this instruction, looks for the requested page and displays it. All this is taking place in the background (back-end). The rendered page is a result of a series of processes that the application on which the website sits does the work. It has to follow a laid down set of instructions to render the requested page.
Model handles data logic. What this means is that the model handles the graphical representation of the data in storage. The storage, in this case, is a database. It handles the getting and manipulation of the data in the database. Some experienced programmers often call it the brain of the application. This is so because it always communicates with both the Controller and can at times manipulate the View as well.
View is the visual part of the application and handles what the user sees (User Interface). The view is usually made up of HTML/CSS. Its interaction with the Controllers can allow it to pass values from the Controller. What this means is that its elements and values can get manipulated by the Controller. A plain HTML/CSS cannot have these functions performed in them. As a result of this, modern frameworks have their respective template engines to allow for functions such as these to be possible. (Erb in the case of ruby on rails and jinja2 in the case of Flask).
Controller is what receives the various inputs from either View or URL(routes). The inputs are usually user input. It handles the processing of the user’s requests. When a user clicks on a link on a profile page, for instance, the command it receives is usually the GET request. During a form submission by the user in the page, the command received as a result of this is usually the POST request. Other requests include the PUT or PATCH and DELETE. The controller handles the retrieval of data from the Model and passes that data to the View. It does somehow act as a middleman between the Model and the View.
When a user clicks on a link, let us say a profile in this case, the action gets treated as an input and is passed down the chain.
The first stage is usually at the routes file in the application folder which handles the routing process. It gets to decide which request gets directed to which controller. When the Controller responsible for handling the given request gets identified, the data gets sent to it.
The responsible Controller handles where the data goes next. In this case, this being a GET request, the instruction gets passed to the Model which in turn queries the database and retrieves the requested data (a user profile with the correct id). The Controller handles breaking down the request in a way the Model will understand.
Once the Model responds to the request, the Controller is then responsible for repackaging the data this time around, the response, and sends it to the View.
In turn, the View updates its view by rendering back the page that got requested with the relevant values to the user in the User Interface.
In conclusion…
The entire explanation is by no means a conclusive interpretation of the MVC architecture. The description does, however, depict the representation of how the MVC can work in the real world.
Underneath, on web development, are a listing of some languages’ web frameworks that use the MVC architecture, with their corresponding frameworks.
Previously published at https://medium.com/@christianotieno/understanding-the-model-view-controller-19e3b9a16f74