April 27, 2009 at 21:01MVC does not exist
The Phantom of the MVC is dead
inside my mind! ..
// instead of an epigraph
This is a compilation from an earlier article, additions and lyrical absences . I do not set a goal for another holivar, I have already argued my own. So do not blame me for the possible lack of answers to your angry;) comments. Yes, and I will not add imho to each sentence; this entire 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 it.
In fact, this is a short form of a more complete statement: “Currently, at the current stage of development of scientific and technological progress, the theory and practice of algorithmization and programming in an object and functional approach, the implementation of the theoretical foundation of the idea of MVC (Model-View-Controller - separation of the program to the Data, their Presentation and Management) is fully impossible. " Once again: we are talking about the impossibility of implementation, corresponding to the theoretical justification of the idea.
Only a few approximations are possible. After some assumptions.
And now, in order:
a) The IEC has no canonical description. And everyone has the right to think about him what he wants.
b) IEC does not have a canonical description upon 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 three divisions of the IEC in application design, forgetting about point b), which often happens, something like this may arise:
This is an unrealizable stalemate.
Any other option is a deviation from the initial 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 user olegchir . The link and the answer "on the fingers" will be lower.
d) In the light of the foregoing, it is especially dangerous to talk about IEC in applications that actually do not have a close relationship with the client side. In my opinion, these are all web applications, with the possible exception of Java applets.
e) All the “implementations of IEC” that I have seen for php (everyone takes roots from phptemplates.org when he was still alive; don’t go there now - there’s someone's empty blog) are not IECs, they are bad emulations. If only because the classic IEC asserts the independence of the three components. Which is missing in these emulations.
Addition: Most likely, some semblance of independence can be emulated on active patterns like Actor, Beholder, Command or the 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 a complete “objectification” of the programming language does not help in the implementation of the IEC.
I saw more than one php project written through forced separation into classes, well, you understand which ones. 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, you 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, it was, hmm, millions of projects.
There is nothing wrong if you use any of the templates allegedly found on the Internet, supposedly by the IEC, or even come up with your own implementation%) Take a closer look at it and you will want to refactor it and refactor it. It is not necessary to call IEC that IEC is not.
In my opinion, it is impossible to think of the IEC as a pattern (pattern) of implementation or development, and even speaking of the IEC as a design pattern, you do not need to put these three letters in the diagram (in the project)%) Better “write the project, the IEC in the 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 an application.
Since it’s common for people to simplify everything, they have simplified it: first they lost the letter, and then the meaning. He dumped everything in a heap, retold to the students, who, of course, could not understand everything.
As a result, we have in the industry: in superiors and team-leaders there are stupid twenty-year-old students driven out of the Bauman, geniuses, there is no collider on them, under whose "leadership" millions of projects and tens of thousands of lines of code are criticized, where normal design and architecture could have cost only hundreds. As a result, there are problems with testing and support, and the flow of kilo rubles flowing past. Past all.
===
And now an example of "objectification". Here is kament habrahabr.ru/blogs/about_cms/56271/#comment_1507929 , which I did not answer. And why did not answer, now I will illustrate you:
It's funny to me, and you?
=== To the
people who are already ready to pour out the flow of indignation, I repeat once again: the main goal of the post is to reduce the material, and recall that MVC is a design example, but not an implementation template. No need to push in the non-shoved. No need to puff 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?
inside my mind! ..
// instead of an epigraph
This is a compilation from an earlier article, additions and lyrical absences . I do not set a goal for another holivar, I have already argued my own. So do not blame me for the possible lack of answers to your angry;) comments. Yes, and I will not add imho to each sentence; this entire 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 it.
In fact, this is a short form of a more complete statement: “Currently, at the current stage of development of scientific and technological progress, the theory and practice of algorithmization and programming in an object and functional approach, the implementation of the theoretical foundation of the idea of MVC (Model-View-Controller - separation of the program to the Data, their Presentation and Management) is fully impossible. " Once again: we are talking about the impossibility of implementation, corresponding to the theoretical justification of the idea.
Only a few approximations are possible. After some assumptions.
And now, in order:
a) The IEC has no canonical description. And everyone has the right to think about him what he wants.
b) IEC does not have a canonical description upon 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 three divisions of the IEC in application design, forgetting about point b), which often happens, something like this may arise:
Suppose the controller receives a signal about the need to change the presentation of the data, turns to the model for data, the model (as a fairly high-level system) accesses the data storage subsystem. And, following the idea of the IEC, it turns to the subsystem controller, which requests its own model, etc. deeper ...
This is an unrealizable stalemate.
Any other option is a deviation from the initial 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 user olegchir . The link and the answer "on the fingers" will be lower.
d) In the light of the foregoing, it is especially dangerous to talk about IEC in applications that actually do not have a close relationship with the client side. In my opinion, these are all web applications, with the possible exception of Java applets.
e) All the “implementations of IEC” that I have seen for php (everyone takes roots from phptemplates.org when he was still alive; don’t go there now - there’s someone's empty blog) are not IECs, they are bad emulations. If only because the classic IEC asserts the independence of the three components. Which is missing in these emulations.
Addition: Most likely, some semblance of independence can be emulated on active patterns like Actor, Beholder, Command or the 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 a complete “objectification” of the programming language does not help in the implementation of the IEC.
I saw more than one php project written through forced separation into classes, well, you understand which ones. 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, you 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, it was, hmm, millions of projects.
There is nothing wrong if you use any of the templates allegedly found on the Internet, supposedly by the IEC, or even come up with your own implementation%) Take a closer look at it and you will want to refactor it and refactor it. It is not necessary to call IEC that IEC is not.
In my opinion, it is impossible to think of the IEC as a pattern (pattern) of implementation or development, and even speaking of the IEC as a design pattern, you do not need to put these three letters in the diagram (in the project)%) Better “write the project, the IEC in the 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 an application.
Since it’s common for people to simplify everything, they have simplified it: first they lost the letter, and then the meaning. He dumped everything in a heap, retold to the students, who, of course, could not understand everything.
As a result, we have in the industry: in superiors and team-leaders there are stupid twenty-year-old students driven out of the Bauman, geniuses, there is no collider on them, under whose "leadership" millions of projects and tens of thousands of lines of code are criticized, where normal design and architecture could have cost only hundreds. As a result, there are problems with testing and support, and the flow of kilo rubles flowing past. Past all.
===
And now an example of "objectification". Here is kament habrahabr.ru/blogs/about_cms/56271/#comment_1507929 , which I did not answer. And why did not answer, now I will illustrate you:
/* Тезисы всё те же: «всё есть объект», «всё есть 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.It's funny to me, and you?
=== To the
people who are already ready to pour out the flow of indignation, I repeat once again: the main goal of the post is to reduce the material, and recall that MVC is a design example, but not an implementation template. No need to push in the non-shoved. No need to puff 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?