MVC does not exist

The Phantom of the MVC is dead
inside my mind! ..
// instead of epigraph

This is a compilation of an earlier article, additions and lyrical omissions . I do not set a goal for another holivar, I have already argued mine. So do not blame me for the possible lack of answers to your angry;) comments. Yes, and I will not add imho to every sentence; This whole article is an expression of my own humble opinion.


')
The statement “MVC does not exist” sounds very harsh and defiant, and many immediately begin to argue with him.
In fact, this is a brief form of a more complete statement: “At the present time, at the current stage of development of scientific and technological progress, the theory and practice of algorithms and programming in the object and functional approach, the realization of the theoretical substantiation of the idea of ​​MVC (Model-View-Controller - program separation on Data, their Submission and Management) is completely impossible. ” Once again: we are talking about the impossibility of implementation, corresponding to the theoretical substantiation of the idea.
Only some approximations are possible. After some assumptions.

And now in order:
a) the ICC does not have a canonical description. And everyone has the right to think about what he wants.
b) the ICC does not have a canonical description after its appearance. It was invented and started to be used by SmallTalk programmers in programming (exclusively!) User interfaces.
c) Moreover, if we fanatically follow the separation of the IEC in the design of applications, forgetting paragraph b), which often happens, something like this can arise:

Suppose the controller receives a signal about the need to change the data representation, calls the model for data, the model (as a sufficiently high-level system) refers to the data storage subsystem. And, following the idea of ​​the ICC, it turns to the controller of the subsystem, which requests its own model, etc. deep down ...

This is an unrealizable stalemate.
Any other option is a deviation from the original separation and removes us from the IEC.
A very good example of just such a situation was put forward as an argument in a failed dispute by the user olegchir . Link and answer "on the fingers" will be lower.

d) In the light of the above, it is especially dangerous to talk about the ICC in applications that actually have no close connection with the client part. In my opinion, these are all web applications, with the possible exception of Java applets.
e) All the “ICC implementations” I have seen for pkhp (everyone takes roots from phptemplates.org when he was still alive; don't go there now - someone’s empty blog is there) are not IEC, they are bad emulations. If only because the classic IEC asserts the independence of the three components. Which is absent in these emulations.
Addition: Most likely, a kind of independence can be emulated on active patterns like Actor, Beholder, Command, or Event-Handler architecture. But this, again, is not a solution for scripting languages ​​like php, in which the real benefit is only from Wrapper.

f) Even complete “objectization” of a programming language does not help in the implementation of the ICC.
I saw more than one pkhp-project, written through compulsory division into classes, well, you understand what. This approach gives a good start, but ultimately led to an extensive build-up of kilobytes of code with almost copy-paste. To work with the code had to include GodMode. In contrast, I can say that I saw kilobytes and completely different code written by a genius. Neither case is supported. Yes, in each case these were, hmm, millions of projects.

There is nothing bad if you use any of the templates previously found on the Internet, supposedly by the IEC, or even come up with your own implementation%) Look at it more carefully and you will want to refactor it and refactor it. Do not call the IEC what the IEC is not.

In my opinion, the ICC should not be thought of as a pattern (pattern) of implementation or development, and even speaking of the ICC as a design pattern, it is not necessary to lay these three letters% into the scheme (in the design). mind. "

===
that was the end of the article

Evil addition:

Few people remember, but what is already there! Few people even know that initially in MVC there were two letters M - MMVC: one M for “business logic” and the other M for the application.

Since it is human nature to simplify everything, that’s how it was added: first, the letter was lost, and then the meaning was lost. They piled everything in a heap, told the schoolchildren, who, of course, could not understand everything.

As a result, in the industry we have: in chiefs and "teammates" - stupid twenty-year-old students, kicked out of Bauman, geniuses on their heads, they don’t have a collider, under whose "leadership" millions of projects and tens of thousands of lines of code are created; normal design and architecture could do with hundreds. As a result - problems with testing and support, and the flow of kilorubles flowing past. Past all.
===

And now an example of "objectization." Here kamant habrahabr.ru/blogs/about_cms/56271/#comment_1507929 , to which I did not respond. And why did not you answer, now I will illustrate it to you:

<?php
/* : « », « MVC». */

class Object extends MVC{}
class Model exteds Object{}
class View exteds Object{}
class Controller exteds Object{}
class MVC exteds Object{
protected _model = new Model();
protected _controller = new Controller();
protected _view = new View();
}
?>

* This source code was highlighted with Source Code Highlighter .

I'm funny, and you?

===

To the habra people who are already ready to pour out the indignation flows, I repeat once again: the main goal of the post is to reduce the material and recall that MVC is a model of design, but not a template for implementation. Do not cram nivpihuemoe. There is no need to puff up and poke patterns and objects everywhere. Why achieve the result of "hard work and perversions" (Quote) when you just need to choose the right development environment and think about the architecture, extensibility and support of the project in advance, before the first line of code is written?