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 ;-)