What is MVC – Wingdings Translator Online

We explain in a general way the architecture pattern of the MVC software (Model – View – Controller or Model – View – Controller). How the different layers are separated according to their responsibilities.

In general terms, MVC is a software architecture proposal used to separate the code by its different responsibilities, maintaining different layers that are responsible for doing a very specific task, which offers various benefits.

MVC is initially used in systems where the use of user interfaces is required, although in practice the same architecture pattern can be used for different types of applications. It arises from the need to create more robust software with a more adequate life cycle, where ease of maintenance, code reuse and the separation of concepts are promoted.

Its foundation is the separation of the code into three different layers, bounded by their responsibility, in what are called Models, Views and Controllers, or what is the same, Model, Views & Controllers, if you prefer in English. In this article we will study these concepts in detail, as well as the advantages of implementing them when we develop.

MVC is an “invention” that is several decades old and was introduced even before the appearance of the Web. However, in recent years it has gained a lot of strength and followers thanks to the appearance of numerous web development frameworks that use the MVC pattern as a model for the architecture of web applications.

Note: As we have already mentioned, MVC is useful for any development that involves user interfaces. However, throughout this article we will explain the paradigm from the prism of web development.

why CMV

The branch of software engineering is concerned with creating processes that ensure quality in the programs that are carried out and that quality attends to various parameters that are desirable for all development, such as program structuring or code reuse, which should influence positively on ease of development and maintenance.

Software engineers are dedicated to studying how software creation processes can be improved and one of the solutions they have come up with is architecture based on layers that separate the code based on its responsibilities or concepts. Therefore, when we study MVC, the first thing we have to know is that it is there to help us create applications with higher quality.

Perhaps, so that the advantages of MVC are clear to all of us, we can use a few examples:

Although it has nothing to do with it, let’s start with something as simple as HTML and CSS. At first, HTML mixed both content and presentation. That is, in the HTML itself we have tags like “font” that are used to define the characteristics of a font, or attributes like “bgcolor” that define the color of a background. The result is that both the content and the presentation were together and if one day we tried to change the way a page was displayed, we were forced to change each of the HTML files that make up a website, touching each and every one of the tags in the document. Over time it was observed that this was not practical and the CSS language was created, in which the responsibility of applying the format of a website was separated.
When writing programs in languages like PHP, any of us start by mixing both PHP code and HTML code (and even Javascript) in the same file. This produces what is called the “Spaghetti Code”. If one day we intend to change the way we want the content to be displayed, we are obliged to review each and every one of the pages that our project has. It would be much more useful if HTML was separated from PHP.
If we want different profiles of professionals to participate in a team and work independently, such as designers or programmers, both have to touch the same files and the designer necessarily has to deal with a lot of code in a programming language that may not be familiar to him. , being that it may only be interested in the blocks where there is HTML. Again, it would be much easier to separate the code.
During the manipulation of data in an application it is possible that we are accessing the same data in different places. For example, we can access the data of an article from the page where the article is displayed, the page where the articles of a manual are listed or the backend page where the articles of a website are managed. If one day we change the data of the articles (we alter the table to add new fields or change the existing ones because the needs of our articles vary), we are forced to change, page by page, all the places where the article data was consumed. Furthermore, if we have the data access code scattered over dozens of places, it is possible that we are repeating the same data access statements and therefore we are not reusing code.

Perhaps you have seen yourself in one of those situations in the past. These are just simple examples, there being dozens of similar cases in which it would be useful to apply an architecture such as MVC, with which we force ourselves to separate our code according to its responsibilities.

Now that we can have an idea of the advantages that MVC can bring us, let’s analyze the various parts or concepts in which we must separate the code of our applications.

Models

It is the layer where you work with the data, therefore it will contain mechanisms to access the information and also to update its status. We will usually have the data in a database, so in the models we will have all the functions that will access the tables and make the corresponding selects, updates, inserts, etc.

However, it is worth mentioning that when working with MCV, it is also common to use other libraries such as PDO or an ORM such as Doctrine, which allow us to work with database abstraction and object persistence. For this reason, instead of directly using SQL statements, which usually depend on the database engine with which you are working, a dialect of data access based on classes and objects is used.

Views

The views, as their name makes us understand, contain the code of our application that will produce the visualization of the user interfaces, that is, the code that will allow us to render the states of our application in HTML. In the views we only have the HTML and PHP codes that allow us to display the output.

controllers

Contains the code necessary to respond to the actions requested in the application, such as viewing an item, making a purchase, searching for information, etc.

It is actually a layer that serves as a link between the views and the models, responding to the mechanisms that may be required to implement the needs of our application. However, its responsibility is not to directly manipulate data, nor to display any type of output, but to serve as a link between the models and the views to implement the various needs of development.

MVC application architecture

Below you will find a diagram that will help you understand a little better how the different layers that make up the software development architecture collaborate in the MVC pattern.

In this image we have represented with arrows the modes of collaboration between the different elements that would make up an MVC application, together with the user. As you can see, controllers, with their business logic, bridge the gap between models and views. But also in some cases the models can send data to the views. Let’s see step by step what the typical workflow would be like in an MVC scheme.

The user makes a request to our website. It will generally be triggered by accessing a page on our site. That request goes to the controller.
The controller communicates with both models and views. It requests data from the models or sends them to perform data updates. It requests the corresponding output from the views, once the pertinent operations have been carried out according to the business logic.
To produce the output, views can sometimes request more information from models. Sometimes, the controller will be responsible for requesting all the data from the models and sending it to the views, bridging the two. Both one thing and the other would be common, it all depends on our implementation; that is why we have colored that arrow in another color.
Views send the user the output. Although sometimes that output can go back to the controller and it would be the controller that sends it to the client, that’s why I’ve put the arrow in another color.

Business logic / Application logic

There is a concept that is used a lot when explaining MVC which is “business logic”. It is a set of rules that are followed in the software to react to different situations. In an application, the user communicates with the system through an interface, but when he activates that interface to perform actions with the program, a series of processes known as business logic are executed. This is a general software development concept.

Business logic, apart from marking a behavior when things happen within software, also has rules about what can and cannot be done. This is also known as business rules. Well, in the MVC the logic of the business is on the side of the models. They are the ones who need to know how to operate in various situations and the things they can allow to happen in the process of running an application.

For example, let’s think of a system that implements users. Users can make comments. Well, if in a model they ask us to delete a user, we must delete all the comments that that user has made as well. This is a responsibility of the model and is part of what is called the business logic.

Note: If we do not want these comments to be lost, another possibility would be to keep the user’s record in the user table and only delete their personal data. We would change the username to something like “Jon Nobody” (or whatever), so that we don’t lose referential integrity of the database between the comment table and the user table (there should be no comments with a user_id which then does not exist in the user table). This other logic is also part of what is called business logic and has to be implemented in the model.

Even in our app…