MVC on the server does not happen

MVC in our time does not use only lazy. Yes, and lazy, too, uses a CMS that implements this approach.
But is MVC it?

An architecture called MVC appeared in the Xerox PARC research lab when developing programs with a graphical user interface (GUI). It is worth noting that programs with GUIs appeared in the same place, and when they appeared, they immediately showed the programming world a new problem. The fact is that GUIs, in contrast to the command line interface, display a lot of different information, some parts of which can be connected, and most importantly, it allows you to interact with this information.

When a user interacts with data, they can change, which means that the data associated with them can also change. For example, the same string is shown in the text box and in the title bar of the window. Rewriting a string - the title should change. The solution "in the forehead": when we understand that the line in the text field has changed, we change the line in the header. But what if the same data is shown in five different places (the data has five views), in each of which they can change? Then, in each data change event handler, you have to write code that updates four other views that display data. If something changes in at least one representation, then it will be necessary to make edits to all handlers. The code is getting too connected.

To solve this problem, the MVC architecture was invented.
')
The essence of the solution:
From the code which changes representation at change of the data not to get to anywhere. He should be. But in one copy. So it should be allocated to the function. And to call this function from all handlers. But wait. The words “when data changes” make it clear that we do not care what event happened. So you can also call the function of updating the views into a function that will be called during any event that changes data. As a result, the code updates the view by itself, and to add a new view of the same data, it is enough to add a function call to the data modification function.

Programmers. or rather, researchers from Xerox PARC loved OOP. And that means they loved what I call the “lift of control” —the transfer of the decision to call some code upstream of the control. This is mainly done through the transfer of the object, which will then be called method. Instead of making a condition in a function, you can make a condition before calling a function, depending on it, create one or another object, and call a function by passing the resulting object there as an argument. What does this give? And the fact that it will be possible to change the behavior of the function by passing different objects to it. The function itself will not be changed.

The same can be done for the function that is executed when the data changes. Let it cause methods of objects. Then you can add views without touching the function. It is a lot of representations, means it is necessary to store objects in an array.

This is the classic MV * architecture. As for the controller, it is still possible to argue, but in all variants there is data, representations and changes in these representations as data changes .

What is the result: MVC solves the problem of strong code connectivity, allowing you to separate the model and the views using some architecture.

If you search on Habré, in Google or Yandex, then the most information is about MVC for web applications. And it says everywhere that when we share data and views, it’s MVC. Such a definition is enough to assume that the application of virtually any design patterns that give us the separation of the system into separate parts is MVC.

UPD: here, under web applications, I understand such applications, all the imaginary MVC of which is concentrated on the server. For example, here is such a simple MVC system in PHP5

But wait. Proper application of OOP in any case will give us a system divided into weakly connected parts.
There are no events in web applications. The HTTP protocol requires us to kill the application after responding to a request, or to pretend that we killed it. So the only event of a web application is its launch with some set of parameters.

And if there are no events, then the presentation is not necessary to update. They are already rendered when created.

In web applications, it is useful to divide the code into business logic, a template, and a controller, but perhaps it is worth calling them with their own names, rather than those used in a slightly different programming area?

UPD: jigpuzzled pointed out that such a separate name for the server architecture already exists: Action-Domain-Responder