Hello, I'm Maneshwar, and I'm building LiveReview — a blast-radius aware AI code review built for your business-critical systems. Star us to help devs discover the project, give it a try, and share your feedback to help improve the product.
A third person mentions VIPER and the room goes quiet, because everyone has a VIPER war story.
I went down this rabbit hole recently and realized something that should have been obvious years ago: MVC, MVP, MVVM, MVVM-C and VIPER are not five different ideas.
Strip away the acronyms and every pattern is arguing about the same three things.
And a translator in between, whose entire job is making sure the View and the Model never talk to each other directly.
That translator is the part that keeps getting renamed. Controller. Presenter. View-Model. Everything else is a debate about how much power to give it, and who else gets to share the job.
Model-View-Controller is genuinely old, coming out of Smalltalk work at Xerox PARC in the late 1970s, which makes it nearly as old as the personal computer itself.
It was built to separate "what the data is" from "what's on screen," and for a single-window desktop app in 1978, that was already a big improvement over one giant blob of code that did everything.
To see where each pattern actually differs, let's run the exact same tiny feature through all five: a user tapping their profile picture to pick a new one.
MVC connects the View and the Model through a Controller that does all the coordinating.
You tap the picture, the View tells the Controller, the Controller updates the Model, and once that's done the Controller turns around and tells the View to refresh.
It reads clean on a whiteboard, and honestly it's a fine choice for a small app. That's not a knock, it's the actual selling point.
The catch is that this Controller doesn't stay this small. Every new feature wants to talk to the Model somehow, and the Controller is the only door in the building.
Six months later it's not a controller, it's a lobby that every department in the company has to walk through.
MVP answers the bloated-controller problem by handing UI logic to a dedicated Presenter, and telling the View to do nothing but draw.
Tap the photo, the View notifies the Presenter, the Presenter updates the Model, formats whatever comes back into something display-ready, and pushes that formatted result straight into the View.
The View in MVP is deliberately dumb, which is a compliment here. A dumb View is a View you can unit test the Presenter against without spinning up any UI at all, since the Presenter only ever talks to a thin interface the View implements.
That testability is the entire reason teams reach for MVP. Not because it's fancier than MVC, but because "does the right thing happen" becomes a question you can answer without a simulator or a device.