The original flaw, if you ask me, is the naming. WTF is a model? WTF is a controller? WTF is a view? You can (and I have) explained this to a newbie for an hour and they still won't get it.
They may as well have named it 123. At least that wouldn't make you guess at what the naming signifies.
Well obviously the nuance is going to be lost on someone who hasn't actually programmed the type of system the pattern refers to. There's no way for someone to grok it without a mental model of what the system needs to accomplish. However with that experience it's really not that hard to understand.
I disagree. That's not obvious. It's relatively easy to explain parallelism, concurrency, recursion, currying, idempotency, the visitor pattern, etc. etc. This is different. MVC names are really annoying and poorly chosen. Every time I think of the pattern, I have to make an association between each word of the pattern and its meaning.
For example, the Model of MVC consists of business logic and sometimes what people refer to as... models. The business logic controls how models are modified. The Controller doesn't. The Controller controls very little when the system is correctly architect-ed, especially when you have multiple UIs.
Really, the View is the only one without ambiguity. But even so, I still have to google from time to time to remember who is allowed to know about who and who notifies who of what...
A better name, and this is literally off the top of my head, would be "Business Layer, View and Event Translator".
Edit: Having thought about it more, I decided to change the word Presentation to View in my "better name" suggestion.
> A better name, and this is literally off the top of my head, would be "Business Layer, View and Event Translator".
That's not far off the original meaning AFAIK. It used to be called MVCU - model-view-controller-user. The "model" is the idea of the data as it exists in the users mind, the view is how the system presents it, and the controller works with what the user "do" with the model through the view.
It gets confused if you don't realize there are two data models: the "data" model - how the data is modelled in the abstract (and confusingly, internally in the program/database) -- that is distinct from the model in MVC. So the original MVC "model" is closer to "domain model" than to "data model".
Now, in the dark 90s, when everyone had forgotten that users existed, something that no-one would realize until "agile" emerged and surprised everyone, these two "models" got mixed up -- and no one was able to understand this MVC thing ;-)
I think it can be explained pretty easily, even if necessarily generalizing.
Model is a representation of the data of your domain and behavior imminently related to this data. I.e. what is "user" and what it means to "create a user"? What does it mean to "find most active users"? The name is because it "models" the domain by representing it as an abstract interface.
Controller is a representation of the rules of when and which models are invoked and which actions are performed. I.e. when we would "create a user"? When we would need to "find most active users"? The name is because it "controls" the models, telling them what to do.
View is how the information presented to the end consumer and how the consumer interacts with it. I.e. what it means to actually show "most active users" to the end consumer? The name is because end consumer "views" it.
Of course, this explanation without actual experience of how such systems are designed and behave does not make a newbie magically able to design complex systems flawlessly. No amount of name changing would. But explaining how this approach works doesn't seem that hard to me.
They may as well have named it 123. At least that wouldn't make you guess at what the naming signifies.