[This post is not my own answer to that question — “What is MVC, MVP, MVVM?…”. This post just contains _a link to the best 
explanation there is about MVC, MVP and MVVM.]_
While searching my notes for a blog post I read before about the two ways of how the “Use Cases/Interactors”, “Presenters”, and “Controllers” interact in an application employing Clean Architecture, I found a note with this image explaining MVC, MVP and MVVM:
It’s from an article written by Erwin van der Valk. — in 2009!
One can clearly see the difference between MVC and MVP-Passive-View in that image; and between MVP-Passive-View) and MVP-Supervising-Controller. The MVVM diagram looks like the MVP-Passive-View diagram, but you will see the difference if you read the article and the next article in the series. (I think the difference is that we can do two-way data binding in MVVM while we cannot (or should not) do it in MVP??)
The article also contains code samples which greatly helps programmers understand the patterns. 
Go on… Read it!…
Don’t you think it is the best explanation of MVC, MVP, and MVVM? their similarities? and their differences?
I was not able to find this article when I was searching a few weeks ago for a good explanation of MVC, MVP, and MVVM. This article does not show up in search engine results perhaps because its title does not contain the words “MVC” and “MVP” and “MVVM”. I hope this blog post will help search engines find this article by Erwin van der Valk.
Enjoy!
Update (May 11 & 12, 2019):
That image above first caught my attention because it puts in one picture some things that I already know (some vaguely at least) about these presentation patterns:
- The MVC diagram seems to match how ASP.NET MVC works: the Controller uses the Model; the View also uses the Model; the Controller chooses what View to show the user; the View tells what Controller methods (or “action” methods) to invoke based on user gestures (for example, if a user clicks on a button in the View, it will invoke an “action” method in the Controller)
- MVP has two variants: Passive View and Supervising Controller
- In the MVP-Passive-View the View does not directly access the Model, while in MVP-Supervising-Controller the View can access the Model
- MVVM is the same as Presentation Model (from this stackoverflow answer)
The image also clearly shows the difference between MVC and MVP-Passive-View because they are placed side by side.
But, after further inspection (and thinking about how each of them will be implemented) …
seems like MVC and MVP-Supervising-Controller looks the same
… and …
MVVM and MVP-Passive-View looks the same (perhaps their only difference is the two-way data binding in MVVM?)
Let’s look at that image again:
Hmmmm…
Also, the sample code for the Controller of MVC has the View passed into the constructor…
1: public class Controller
2: {
3: private readonly IView _view;
4:
5: public Controller(IView view)
6: {
. . .
… that looks like a Presenter class in a project I was involved in a few years ago. It seems like I can just rename the “Controller” class into “Presenter” to to be able to transform it from MVC to MVP!
1: public class Presenter
2: {
3: private readonly IView _view;
4:
5: public Presenter(IView view)
6: {
. . .
See!? 
These patterns look the same to me now… At least MVC and MVP… They look the same…
I wonder if they are just the same pattern given different names by different people who encountered somewhat similar problems, but are living in different places from different times in history.
Perhaps not.
But if they are all the same then that explains the confusion of many (including me) when reading stackoverflow answers to questions like “What is the difference between MVC, MVP and MVVM?”.
Consider these images which I found being used to compare MVC, MVP and MVVM in an answer to a stackoverflow question:
Confusing, right? In the MVC of the top image, the arrow points from the Model to the View; while in the MVC of the bottom image, the arrow points from the View to the Model.
Then consider these comments regarding that answer:
“Please don’t just copy images - especially when they don’t agree among themselves. See [the examples for] MVC — ‘browser talks to view’ in top picture, but ‘talks to controller’ in lower picture.” — peter.fr
“In the first diagram what is the difference between MVVM and MVP? As I see it, it is only the links between the V and the VM/P. Which in one case has the back and forth messages as a bidirectional link and in the other they are represented as two unidirectional links. I don’t see any functional difference between them. What am I missing?” — iCyberPaul
Confusing!
This makes me remember what Jimmy Bogard said during the first few minutes of one of his recorded talks — when he compared the Traditional N-Tier architecture with DDD-style N-Tier architecture:
“… looks like they just changed the name of things”
It seems like MVC, MVP and MVVM also are just like that — “looks like they just changed the name of things”. Seems to me that confusion like this is prevalent in our industry 
(perhaps because it is still very young, as they say).
(They also say that these “architecture” things in software — Onion Architecture, Hexagonal Architecture, Ports and Adapters Architecture and Clean Architecture — are all the same, but look at all those names!)
Also, the person who used that “MVC, MVP, MVVM” image where I first saw it said this:
You can use many different ways to communicate between modules and call it MVC. Telling me something uses MVC doesn’t really tell me how the components communicate. That isn’t standardized. All it tells me is that there are at least three components focused on their three responsibilities.
Some of those ways have been given different names: . . .
[image inserted here]
And every one of those can justifiably be called MVC.
Hmmmm…
Perhaps they are all the same — They are in a sense! — they separate the Presentation Logic from the View. Perhaps the implementation in code will only differ due to some limitations or/and features of the UI framework that we use(?)
This gets me into thinking that if we are employing a Presentation Pattern in our application, perhaps it’s best if we just call it MVCPVM (or something like that) instead of MVC or MVP. And if a new team member asks “What is MVCPVM?” then we just let him see our code and show him “how the components communicate”, and that “we intend to separate the Presentation Logic from the View”… because if we tell him “We are using MVC!” (or “We are using MVP!”), he might already have a different understanding of what MVC (or MVP) is than how we do it in our codebase. And if he studies our codebase and comments “I don’t think that’s MVC (or MVP)” there will be war.
