"MVC" has become an increasingly popular buzzword in the web development community but what exactly does it mean? Over the last 20 years, websites have gone from simple HTML pages with a bit of CSS, to incredibly complex applications with thousands of developers working on them. To make working with these complex web applications much easier, developers use different patterns to lay out their projects to make the code less complex and easier to work with. By far the most popular of these patterns is MVC also known as Model View Controller. The goal of this pattern is to split a large application into specific sections that all have their own purpose. To illustrate each section, let's look at an example where a user is requesting a specific page from a server.
MVC Diagram
Controller
The following diagram illustrates server-side logic, that follows MVC architecture, which occurs when a request from a client is received. Based on what URL is being requested, the server will send all the request information to a specific controller. The controller is responsible for handling the entire request from the client and will tell the rest of the server what to do with the request. It acts as a middleman between the other two sections, model and view, and should not contain very much code. The first thing that happens when a controller receives a request is asking the model for information based on the request.
Model
The model is responsible for handling all of the data logic of a request. This means that the model interacts with the database and handles all validation, saving, updating, deleting, and any other CRUD related actions of the data. The controller should never directly interact with the data logic. It should only ever use the model to perform these interactions. This means that the controller never has to worry about how to handle the data that it sends and receives and instead, only needs to tell the model what to do and responds based on what the model returns.
This also means the model never has to worry about handling user requests and what to do on failure or success. All of that is handled by the controller whereas the model only cares about interacting with the data. After the model sends its response back to the controller, the controller then needs to interact with the view to render the data to the user.
View
The view is only concerned with how to present the information that the controller sends. This means the view will be a template file that dynamically renders HTML based on the data the controller sends it the view. The view does not worry about how to handle the final presentation of the data, but instead only cares about how to present it. The view will send its final presentation back to the controller where the controller will handle sending that presentation back to the user. The important thing to note about this design is that the model and the view never interact with each other. Any interactions between the model and the view are done through the controller.
Putting It All Together
If we consider real-world applications of this we can think of some web-apps that we interact with every day, say for example any social image-sharing app. Imagine a user sends a request to a server to get their photos. The server would send that request to the controller that handles photos. That controller would then ask the model that manipulates the photos collections or tables in the database to return a list of all photos. The model would query the database for a list of all photos and the return that list back to the controller.
If the response back from the model was successful, then the controller would ask the view associated with photos to return a presentation of the list of photos. This view would take the list of photos from the controller and render each photo element in the list into any HTML format that could be used by the browser. This is how image galleries are rendered.
The controller would then take that presentation and return it back to the user, thus ending the request. If earlier, the model returned an error instead of a list of photos, the controller would instead handle that error by requesting the view that was created to show the errors or the HTTP error code that was returned. Most commonly recognized by web-users
as the “404 Not found page”. That error presentation would then be returned to the user instead of the image gallery. In summary, the model handles all of the data, the view handles all of the presentations, and the controller tells the model and views what to do. This is the idea behind basic MVC architecture and is how many applications maintain a manageable and organized codebase.
Top comments (3)
Nice article. I want to share with you, my own boilerplate for node api. Central error management, components structure etc and more
github.com/mikesavvakisnet/express...
I loved this article.. Really educating..
Thank You Kingsamuel! Let me know If there are any other web dev concepts you'd like me to cover:)