Websites have evolved from simple HTML pages with a bit of CSS to incredibly complex applications with thousands of developers working on them over the last 20 years. To make working with these complex web applications easier, developers use different patterns to lay out their projects, making the code less complex and easier to work with MVC, also known as Model View Controller, which is by far the most popular of these patterns. The goal of this pattern is to divide a large application into distinct sections, each with its own purpose.

To illustrate each section, consider the following scenario: A user requests a specific page from a server based on the URL the user enters. The server will route all request data to a specific controller. This controller is in charge of handling the entire client request and instructing the rest of the server on what to do with it. It serves as a bridge between the other two sections, model and View, and should contain little code. When a controller receives a request, the first thing it does is ask the model for information based on the request. The model is in charge of handling all of the request's data logic.

This means that the model communicates with the database and handles all data validation, saving, updating, deleting, and so on. The controller should never interact directly with the data logic and should always use the model to do so. This means that the controller never has to worry about how the data it sends and receives is handled, but instead only needs to tell the model what to do and respond based on the model's output. This also means that the model never has to worry about how to handle user requests or what to do in the event of failure or success. The controller handles everything, and the model only cares about interacting with the data.

After the model returns its response to the controller, the controller must interact with the view in order to render the data to the user. The view is only concerned with how to present the data sent by the controller. This means that the view will be a template file that dynamically renders HTML based on the data sent to it by the controller. The view is not concerned with how to handle the final presentation of the data, but rather with how to present it. The view will return its final presentation to the controller, who will then return that presentation to the user.

The most important aspect of this design is that the model and view never interact with each other. The controller handles all interactions between the model and the view. By placing the controller between the model and the view, the presentation of data and the logic of data are completely separated, making it much easier to create complex applications. However, this is all hypothetical. Let's take a look at how this design handles a request.

For instance, Assume a user makes a request to a server for a list of Dogs🐶. The server would route the request to the controller in charge of dogs. That controller would then request a list of all dogs from the model that handles dogs. The model would query the database for a list of all dogs, which it would then return to the controller. If the model's response was successful, the controller would request that the view associated with cats return a presentation of the list of dogs.

This view would take the controller's list of dogs and render it into HTML that the browser could use. The controller would then take that presentation and return it to the user, effectively completing the request. If the model had previously returned an error rather than a list of dogs, the controller would handle that error by requesting that the view that handles errors render a presentation for that error. Instead of the catalyst presentation, the user would be shown the error presentation. As that example shows, the model handles all of the data, the view handles all of the presentations, and the controller simply tells the model and view what to do.

Clone this repo for the entire source code

Model

Controller

View