I want to hear the advantages of the MVC pattern. The options are comfortable, not beautifully suited. How the pattern Model-View-Controller works is known. But what are the clear advantages?

Closed due to the fact that the issue is too general for the participants Vitaly Emelyantsev , rdorn , Grundy , Kromster , Alexey Shimansky 10 Oct '16 at 6:17 .

Please correct the question so that it describes the specific problem with sufficient detail to determine the appropriate answer. Do not ask a few questions at once. See “How to ask a good question?” For clarification. If the question can be reformulated according to the rules set out in the certificate , edit it .

  • 2
    I think you don’t know how it works, otherwise you would know its advantages - ampawd
  • And if I want to write cons - Alexey Shimansky
  • Write and cons) - user2455111
  • ampawd Yes, I myself am in shock, it's like working for two years, and then not working with a shovel and forgetting why it is needed - user2455111

3 answers 3

In MVC, the application logic is clearly separated, and this, in turn, simplifies the work on large projects to a great extent.

Plus will be the same:
1) Convenience to display different views (views) for different types of devices, while using the same data;
2) Facilitates support and testing code.

  • 3) code reuse - Vyacheslav Danshin
  • This is not only the privilege of mvc. The answer did not suit ("The options are convenient, they do not fit nicely." 1st point is a good answer - user2455111
  • @ user2455111, then I'm sorry, I did not find any more benefits. What did you expect from MVC? - Ep1demic
  • xs, I used it for 2 years, but I don’t see any decent advantages, and I didn’t fill up this question at the interview. Namely 1) Convenience to display different views (views) for different types of devices, while using the same data; Thank! - user2455111
  • @ user2455111 then perhaps you should have asked this question directly with the person conducting the interview, and not here?) - Ep1demic

Here is just the option is convenient and beautiful, as with all the patterns to the article. The division of roles according to MVC is beautiful and convenient because it is strategically advantageous in large projects with a rich graphical interface. It, so to say, responds to how the system sees the developer. Allows you to well localize changes in these individual entities so that the likelihood of their simultaneous changes is lower. Let's take a look at the main reasons for the changes:

  1. Changing the data structure - the model changes the most, the controller is smaller, and the view may not have to be changed at all.
  2. Changing the logic of the interface - the presentation changes more, then the controller, the model is even smaller.
  3. Correction of errors - first of all they are easier to find, and secondly, testing is simplified.
  4. Large structural changes - it becomes easier to plan, break into stages.

The project becomes more manageable and predictable, and this is one of the main design goals.

  • Correction of errors - first of all they are easier to find, and secondly, testing is simplified. How is testing easier? - user2455111
  • @ user2455111 So that it can be automated by writing tests. - Cerbo
  • Changing the logic of the interface will most often be caused by a change in the logic of the application as a whole, and then the domain model will most likely change first. The data structure changes -> the controller automatically changes the input, and it changes no less than the model. - etki

mvc - created for one, put the application logic on different layers and what is best to call assets.

But first of all it is necessary to turn to the roots and understand the ареал in which this парадигма or as it is often said, the multipattern was cultivated.

The concept was described by Trygve Reenskaug in 1979 for the Smalltalk ...

I will digress and allow myself to assume that a developer or php or html > css > js running through the previous sentence will pay attention only to the strange name of the old language Smalltalk and continue to read the concept without even knowing that he will not fully understand it!

Smalltalk is the language in which both the server and the client are written, it has no division into a client (such as html , css , js ) and a server ( php , python , ruby ). You must imagine that to create a button you only need to create its object. What is a button? This is a picture and logic of changing skin and events. And all this is already encapsulated in the button object. It's like today html , css , js taken together.

And when they say that mvc shares the logic, they don’t mean to divide the button, but it means the separation of components and control logic of these components. that is, mvc in its original source, this is the rule for the application, not for the component.

But time shows us how not understanding the words of a person who writes on Smalltalk , programmers have learned how to break everything up into components, including components. Good or bad hard to say. Today, speaking of a client-server application, we assume mvc or mvvm on the client and mvp on the server, but in the primary source the concept of the client was not, there was a presentation. Imagine that the browser is a view, and the server is a model. As it would be difficult to say, the only thing that can be guessed today is that the applications of those years and today are different. Well, what applications were in the 60s? Mathematical and probably again mathematical, browsers probably did not even exist.

So, returning to mvc .. The main benefit of it in the economic strategy. That is, when creating applications that will develop and on parts of which applications will be created in the future. After all, today's applications are mostly written for a specific task. Take a regular site, it was written and forgotten, there is no chance that it will refactor. Or for example take a big game where artificial intelligence will be used from the game to the game.

Or recall the rule that the application logic should be in the model. but there is still not a vowel rule that a game or any application is a model. In such cases, the model is always the same, and only the views change. In the best traditions, this is a model that can fully function without other elements. so I can write a sea battle for 2D and 3D and save on programmers.

Everything, there are no other advantages to this paradigm and they have not even been laid.

And the cost is to end with the fact that mvc not the last spur - it is not a single monolithic architectural solution. This paradigm, as I said earlier, is a connecting part and it is absolutely indifferent what to connect. This is not a home, this is a framework application. And as walls and ceilings you can use anything, as well as smaller mvc .

  • About component trends is very controversial, rather the trends go in the direction of the frameworks / libraries. Components fell short of expectations. And yet, what is the advantage of MVC? - Cerbo
  • @Cerbo, but in fact they are still not there .. And don't the frameworks evolve towards components? The reactor has components, and angular 1 and 2 are also components. it will not take long before they understand why the architecture of client and server applications are not as smooth as the books promised. The thing is that in the original the client was just a view, and the model was a server. This is if one sentence. And web components, real, native, still seem to be supported in one browser, and even then not in full measure. - user220409
  • You and I have apparently different components. The idea of ​​the components was to reuse the code (as always, incidentally), that is, the ideologues spoke literally - you made the component, solved the problem, and then "inserted" it in another place without changing it and the whole problem was solved. So, it turned out that the components are "inserted" with great difficulty elsewhere! Because in another place another problem is solved and the environment is different there. - Cerbo
  • So it turns out that in order for a component to be “inserted” in another place it must be designed and implemented for this place in advance. But in this way we return to the libraries / frameworks - they are a better solution. Components occasionally skip, but not because their idea is good, but because the task comes across conveniently. - Cerbo
  • @Cerbo, what you describe most likely elements. A component is an object that must be reused. It encapsulates logic and representation. In the concept of web components, this is just present, because they have their own scope for css and js. Here personally, the angular and the reactant components are very reused, what else to say :) - user220409