What is MVC, really?
As a serious programmer, how do you answer the question What is MVC?
In my mind, MVC is sort of a nebulous topic — and because of that, if your audience is a learner, then you're free to describe it in general terms that are unlikely to be controversial.
However, if you are speaking to a knowledgeable audience, especially an interviewer, I have a hard time thinking of a direction to take that doesn't risk a reaction of "well that's not right!...". We all have different real-world experience, and I haven't truly met the same MVC implementation pattern twice.
Specifically, there seem to be disagreements regarding strictness, component definition, separation of parts (what piece fits where), etc.
So, how should I explain MVC in a way that is correct, concise, and uncontroversial?
Note: If you are working in ASP.NET, MVC has a second, non-nebulous meaning: ASP.NET MVC
MVC has been explained well here https://www.codespeaker.com/blogs/understanding-model-view-controller-mvc-with-real-world-example/
MVC is a software architecture - the structure of the system - that separates domain/application/business (whatever you prefer) logic from the rest of the user interface. It does this by separating the application into three parts: the model, the view, and the controller.
The model manages fundamental behaviors and data of the application. It can respond to requests for information, respond to instructions to change the state of its information, and even to notify observers in event-driven systems when information changes. This could be a database, or any number of data structures or storage systems. In short, it is the data and data-management of the application.
The view effectively provides the user interface element of the application. It'll render data from the model into a form that is suitable for the user interface.
The controller receives user input and makes calls to model objects and the view to perform appropriate actions.
All in all, these three components work together to create the three basic components of MVC.
+1 I really prefer to think of MVC as an architecture of three (or more) patterns, than a design pattern. There's no canonical implementation, it simply isn't that small, and all implementations will have quite a few more than the implied core components.
@YannisRizos Agreed, MVC is definitely more of an architecture for applications than a single design pattern. Plus, there's three distinct parts to MVC, even if presenting the concept to an idiot, it's just not right to say they're all one. What is right is to explain how they all work together as one.
Though this answer has 21 upvotes, I find the sentence "This could be a database, or any number of data structures or storage systems. (tl;dr : it's the data and data-management of the application)" horrible. The model is the pure business/domain logic. And this can and should be so much more than data management of an application. I also differentiate between domain logic and application logic. A controller should not ever contain business/domain logic or talk to a database directly.
I cannot disagree more with this answer simply because it claims mvc to be rational outside the presentation layer. The rest of the answer is ok. MVC should start and end at your presentation layer and absolutely should not have your business logic and repository in it. Doing so effectively places your entire application in your presentation layer and makes no available API which would allow direct access to your business logic or pure data without it being designed for the originating app. This is not open for extensibility, view models get you closer but you're still missing loose coupling
@Jimmy: In many constructions of MVC, the models can be reused in APIs because they do not have dependencies on the UI -- the separation between view and model takes care of that. But that depends, of course, on how you choose to define 'model'. If you are going to make a judgment about MVC, you should first explain _which_ interpretation of MVC you are using.
@Yannis: This just begs the question: What is an architecture of patterns? Why wouldn't you call that just another design pattern? The very definition of design pattern in GoF (and Alexander) makes it quite clear that patterns ought not prescribe one canonical implementation (though the popularity of both books undercuts that notion a bit).
@Bob: I think the part of the definition that needs the most work is the part about the model. "Fundamental behaviors and data" doesn't really explain how the model varies from the behaviors and data that belong to the view, or the controller. You might start by answering this: Why is it called the model? In addition, I think any definition of MVC should explain in more detail what the separation between view and controller is and why, for in many so-called MVC implementations they are fused together.
I dont see how this answer provides more information than the original question itself ...
Just an addition: Model or View or Controller classes are not (as some frameworks, or programmers, like to do), but layers. For example, ProductModel.class not confuse with the Model layer.
I think the following keywords should be kept in mind while thinking of MVC: code modularity, understandability, loosely-coupling. MVC is actually implemented because it successfully conforms these things while developing software.
@Falcon wile i see where you're coming from, MVC actually does not differentiate between that and it is completely fine when controller communicates with the database directly. it's just the decision of modern frameworks, such as laravel or others, of where to take the mvc further to make it cleaner