web and MVC: debriefing

Inspired by the topic of death MVC .

To understand what is happening, let's go from the principles of the PLO.
The object class in OOP encapsulates object data with its behavior.
All the complexity in the division of the subject area into objects.
Here, under the "subject area" I also understand the technical environment (database, network, etc.)

A common practice today is the creation of lightweight POJO-objects and their proxy, which we use some logic, spaced across all parts of MVC (for M, V and C, respectively).
This is convenient from the point of view of implementing various technologies for the M, V and C parts of the application, respectively. At the output we have M-framefork'i, V-framefork'i and C-framefork'i (sometimes there is confusion). In this paradigm, transferring logic to the POJO-classes of the model, which are reflected (mapping) on ​​the database, would be suicide.
')
What alternatives do we have?


Let's go from the principle that objects in OOP encapsulates object data with its behavior. And also we will use the principle of common responsibility.
“What follows from this? To transfer the code for working with the database in essence? ”Of course not.
Let's see. These same POJO objects actually carry a well-defined semantics - the mapping of database entities. However, it is incorrect to call them classes. From the point of view of OOP, it is rather just data structures. And get / set methods are not needed here - it's just a data cast.

It is confusing. Where, then, is the PLO? Let's start from the domain, namely from the operations, user actions. First, let's leave the view from MVC in its place - more or less everything is clear with it, and there are usually no questions. It remains M and C. What is what?
Almost in any web application (consider the web for example, ok? The rest is by analogy) there is work with an external data source, integration with external systems both at the input and at the output, as well as the request / response paradagm. It is logical that request and response are wrapped well in objects, this way has long been passed. There is also an external (technical) interface for the external system to both the input and the output. Those. these classes and objects are already considered. We also take into account the convenience of a declarative style.

So let's say we have an operation. let's say one request. The template and data manager will be determined by the final processor. And it is the final one - all branches dependent on the URL structure, privileges and transmitted data must be made by the dispatcher. In this case, the dispatcher may be partially provided with the framework, but almost never fully. So, the dispatcher was identified, rigidly separated from the rest of logic. At the same time, it operates with either request data or entity objects, i.e. data structures.

Next, the request is processed. Any operation can be divided into primitive CRUD-components performed under various conditions. Question: Is the operation an object? Operation is the interaction of objects. She does not have her own data - she borrows them. It provides the interaction of objects that are passive in themselves. And they are passive because none of them lack the knowledge to perform the operation. Consequently, we need a mediator who will assume responsibility for the interaction of objects. This is NOT a controller. This is NOT a model. This is a different pattern.
What about M and C? The controller should invoke the operation and, based on its results, select the view to be displayed. All logic goes into operation. And where is the model? The model should inform the view of changes, should be changed by the controller ... Our model is the database. The database itself is a model. And without view. In our web development, no component updates the view on events from the model. We build the view based on the data obtained after the operation.

So is MVC it?
In canonical form - no. In the web, another pattern works where the model is passive.
I will not argue about the names, but the structure of the interaction and the role here are different.

Is it possible to make a full MVC?
On this subject, I think you need to write a separate article.