MVC - in general

To describe what MVC is is probably unnecessary nowadays. But for the sake of completeness, it is an application design philosophy, in which the application is divided into three separate but interconnected parts: Model, View, Controller

Model

The part of the application that works with data. It is a purely abstract concept. Some kind of database, tables and so on immediately comes to mind, but it is not always the case. It can be connecting to another party's system, working with some API, operations focused on calculations rather than data structures, working with files and yes even working with a database. It's simply working with data and information in various forms - any form. It doesn't have to be (and in practice often isn't) straight SQL, ORM and the like.

It is important that this part of the application is really focused on working with data and information. But not for interaction with the end user, or presentation of the user interface.

Let's say that the model is really, for example, some kind of work with a database. For example, with articles in the editorial system, or products in the e-shop, or user accounts of a community website. Yes, such a model will definitely work with a database. But it no longer solves, for example, how to display the datagrid element to the user, or how to capture and evaluate input.

Or the model can simply be a client of an API. For example, connecting to the carrier or to the billing system within the e-shop. This is also a model.

View

The part of the application that makes sure everything the user sees is displayed. In our world of online applications, this is usually (but not exclusively) the HTML generation.

It is not true that this part should not contain logic. Not at all. For example, you can't do without cycles and conditions here (it's a great masochism to try to have no sense and no justification). Some logic is a fixed and integral part of efficient HTML generation, which becomes the user interface of your application, information system, e-shop, entertainment portal, simply anything you can imagine.

But you will certainly not call and execute SQL queries in this layer. For example, this part has nothing to do with using CURL to work with a REST API, etc. All of this should be included in the model. The view "only" displays what is required of it, based on the data that is passed to it (usually by the controller), or that the view itself "gets to" by calling part of the model (this is also a legitimate way if it is more efficient for the given situation).

Simply put, you will find everything needed for efficient output generation (i.e. HTML, XML, or even the email body) in the view. But nothing else. The work with the data is done by the model. The view only generates output based on data and information provided by other layers and components.

Controller

This is an abstract term for the logic that controls everything and can take various forms and be more or less complex logic. It is actually what connects the entire application into a functional unit.

It contains everything that is not in the Model and View sections.

In other words: No data is worked with in the controller, certainly no client for anything is implemented there, certainly no SQL query has anything to do there.

But inside the controller you will certainly be interested in, for example, the URL of the HTTP request, what is in the POST and GET data, what is in the session and the like.

You could say that the controller examines the state of the application, what the incoming HTTP request actually means, and what will happen based on that.

Does the user want to create a new item in the administration? The controller determines that this is the case. It creates a new instance of the item (i.e. the model), takes care of everything that needs to be done (for example, calls the form capture and finds out if the user is already saving the item), and finally calls the view to take care of generating the necessary HTML.

Or does the e-shop management user want to create a shipment with the carrier? Again, the controller takes care of evaluating the situation. It asks the model to evaluate the correctness of the input, then it asks the model to perform the required action and finally passes everything to the view to display the result (e.g. the numbers of the created