First off, as an experiment, go ask a coworker/programming friend this unfair question: "What really is MVC?". Once they're done either nonchalantly explaining benefits of separating duties between Model-View-Controller perhaps even using the word 'coupling', or (if they truly didn't know the acronym) itching their head, you can come back.
In this post I'll summarize what MVC really is, how the term became nearly meaningless, and some funny examples of people defending the non-sense terms that are used to define MVC today. Lets start off with learning what MVC was when it was first introduced.
Believe it or not, MVC came from one person (sounds insane for the amount of praise MVC 'frameworks' have received right? Its funny people don't reference the original author more 🤔). It was first defined here . After reading this definition multiple times over, the original definition suggests three concepts to me: 'a view should never know about user input', the somewhat-vague definition of what a model, view and controller is, and that the MVC design appears to be describing a design for user interfaces.
The first point can be cleared up if we get rid of the noise in that quote and add some generality we are left with: some parts of your software should never know about anothers'. Sure, this is… OK advice. I mean it is what the Agilers have been regurgitating for years now since then: Separation of Concerns . If you don't know already: Separation of Concerns is common sense. If you don't know why, I give an explanation here: Separation of Concerns is common sense .
The second point is defining the parts of MVC. Now this is more important than the last point. To go off of my flashlight example in "Separation of Concerns is common sense", assume you didn't know the atomic parts that make up a flashlight. Assume you didn't know that a flashlight generally has two parts: a source of electricity, the rest of the circuitry that makes up the flashlight (bulb, wiring, maybe other circuits). How would you ever know where to practice this "Separation of Concerns"? I don't think anyone would. You need to define the atomic parts of a problem in order to separate duties.
Therefore, making the definition of Model, View, and Controller completely necessary. The original MVC definition defines what the atomic parts of a user interface are. It is frustrating that along with that definition we get a bunch of random noise that talks about the common sense that is 'Separations of Concerns'. Breaking problems down into their smallest parts does prove to be useful (think of how something like an interpretor is broken down to atomic parts: lexers, parsers, evaluators).
The final point is that it seems this definition was specifically used for user interfaces. I have gathered this from the wording which mentions things such as key presses, and other people's views on the article.
This comment is straight gold . At the time of me writing, this answer has 76 votes, and is the 3rd highest answer to the question of: "What is MVC, really?". To paraphrase, the answer explains how MVC is mostly a buzzword today. It has lost nearly all of its original meaning/context. The answerer belittles MVC to 'common sense', saying that telling someone to use MVC is like telling someone to 'breathe air'.
This answer had outrage from multiple commenters. Most of which were hilarious. My favorite comment said this answer 'does a disservice to the OP'. If I were OP, I would want to know the real answer, not to follow the blind herd.
My opinion on this comment is that the author is mostly correct. But, I like to make the distinction between the idea of MVC, and the idea of 'Separation of Concerns'. I would argue that it is not always obvious what the atomic parts of a problem are. For example, if I were to be the first one to write a programming language interpretor, it would not be extremely obvious that there are in fact (loosely speaking) concrete steps: tokenization, parsing, and evaluation. The original definition of MVC has defined what those atomic parts are for user interface design. So that step was not exactly 100% common sense. However, I believe 'Separation of Concerns' is 100% common sense. I'll also agree that today's interpretation of MVC is out of context. The original definition was in the context of user interfaces, but now nearly all MVC 'frameworks' are for web server development.
There are many more StackOverflow questions/answers just like this one, where people give absolutely ridiculous answers to the question: "What is MVC". All of which are meaningless answers (except for the few who give the true answer of which are attacked). Most of these use the words Model, View, and Controller in their definition, as if it is something normal people are supposed to know.
Discovering that Martin Fowler has realized that MVC is no longer what it used to be made me very happy that I'm not alone. He said this back in 2006. All of this actually is puzzling, because some of the people who LOVE their broken definitions of MVC are the same people who praise these Agile leaders like gods 🙇. Seems like they need to actually read what their gods say 😏.
While I believe MVC is misunderstood even from its original definition, at least Martin can confirm that when people refer to as MVC now, is NOT the same as the original MVC definition.
C# has a framework called MVC which has done significant damage to what the original definition of MVC actually means. An MVC C# project by default has "controllers" as normal C# (.cs) files, "views" as Razor (.cshtml) files (Razor is a mutant C#/HTML language), and typically uses another framework, Entity Framework (EF), as its ORM . "Model"s are created by writing classes and subclassing the correct EF classes.
At first glance this appears to be harmless. Views create HTML which acts as a representation of a model. That sounds roughly about right. Assuming you have views which align to each model uniformly (this rarely happens). Controllers… well that's where this all starts to lose its relationship to the MVC design. According to the original definition of MVC: "The controller receives such user output, translates it into the appropriate messages and pass these messages on to one or more of the views". Well… first off, there is nothing about this framework that makes your controllers only talk to views. Controllers often times can and will do whatever they want. There are controllers which could modify models, insert new ones, perform queries on models, etc… Second off, this definition obviously was not meant for web servers. There is talk of "user output", there isn't mention of this being a web server endpoint (as it usually is in MVC Framework). At this point it seems C#'s MVC Framework fits the original MVC definition, if you bend the rules a little bit. But nothing I mentioned here is anything I'm concerned about.
The damage C#'s MVC Framework has caused is that this now has created two completely different meanings of the term MVC. In fact, it disconnects MVC as a design into MVC being types of files. It has gotten to the point where people on StackOverflow suggest that if you are doing any sort of logic in your Razor files (.cshtml), you are doing MVC wrong by putting controller logic into your views. This is bogus. MVC is not a collection of files, MVC is a design. Traditional controllers could exist in your C# MVC's View files (.cshtml). There is absolutely nothing wrong with where the controller's code is. The MVC design states that when you mix your logic with presentation is when you are not following the MVC design anymore. I agree with that. Relating this back to making an interpretor, mixing logic with presentation (so-called "Controller" with "View") seems a lot like mixing tokenization code into a parser. There is simply no sense in doing that.