Оффлайн
- Регистрация
- 1 Мар 2015
- Сообщения
- 1,481
- Баллы
- 155
You’ve probably seen these acronyms flying around in architecture talks, framework docs, or job interviews: MVC, MVP, and MVVM.
They’re not rival K-pop bands — they’re tried-and-tested design patterns that help you write clean, maintainable code by separating concerns between UI, data, and logic.
So, if you’ve ever looked at a messy spaghetti codebase and thought "This could use some structure", welcome.
Let’s untangle these patterns one by one, and see when and where each one fits.
MVC – Model View Controller
Imagine your app is a play. MVC is the classic trio:
This is where your data and business logic live.
Think of it as the backend of your app’s brain — database interactions, validation rules, and calculations all go here.
View
The View is the dumb, pretty layer.
It only knows how to show stuff — like buttons, charts, or loading spinners. No brain here, just glam.
Controller
When you click a button or submit a form, the Controller takes the input, processes it (usually via the Model), and decides what View to show next.
It glues everything together.
In Web Dev:
In Android:
MVP to the rescue.
MVP evolved from MVC, mostly to make unit testing easier and decouple your UI logic from the Android lifecycle.
Model
Same as MVC — it's your data layer.
View
Still dumb, but now even more hands-off.
It just exposes methods like showUserProfile() or displayError().
It doesn’t decide what to show — just how to render it.
Presenter
The real boss here.
Presenter grabs user input from the View, talks to the Model, and pushes the right data back to the View.
The beauty? View and Presenter talk via interfaces — so you can swap out the View during testing without breaking a sweat.
In Android MVP:
MVVM is the new-age cool kid, popularized by frameworks like Angular, React (kinda), Vue, and especially in Android with Jetpack libraries.
The key superpower here? Two-way data binding.
That means when your data changes, the UI updates automatically. And when users interact with the UI, the data layer updates in sync — without you manually pushing things around.
Model
Still your data/business logic — just like always.
View
Now even more passive.
Thanks to data binding, it doesn’t even need to call methods on the ViewModel.
It just reacts to data changes.
ViewModel
This is your middle layer.
It holds UI state and handles interaction logic.
Unlike Presenter, it doesn’t tell the View what to do directly — it exposes observable properties, and the View listens.
In Android MVVM:
TL;DR – Pick Your Pattern
When Should You Use What?
In the wild, you’ll see hybrids.
React devs use MVVM-ish logic with hooks and state management.
Vue and Angular lean toward MVVM.
Classic web apps? Still MVC or even MPA chaos.
And Android? MVP ruled for a while, but MVVM is now the go-to thanks to Jetpack ViewModel, LiveData, and Compose.
Final Words
Patterns aren’t rules — they’re guides. Use what fits your team, tooling, and sanity level. And if all else fails, ask yourself:
I’ve been actively working on a super-convenient tool called LiveAPI.
helps you get all your backend APIs documented in a few minutes
With LiveAPI, you can quickly generate interactive API documentation that allows users to execute APIs directly from the browser.
If you’re tired of manually creating docs for your APIs, this tool might just make your life easier.
They’re not rival K-pop bands — they’re tried-and-tested design patterns that help you write clean, maintainable code by separating concerns between UI, data, and logic.
So, if you’ve ever looked at a messy spaghetti codebase and thought "This could use some structure", welcome.
Let’s untangle these patterns one by one, and see when and where each one fits.
MVC – Model View Controller
Imagine your app is a play. MVC is the classic trio:
- Model is the script.
- View is the stage.
- Controller is the director telling actors what to do when the audience reacts.
This is where your data and business logic live.
Think of it as the backend of your app’s brain — database interactions, validation rules, and calculations all go here.
View
The View is the dumb, pretty layer.
It only knows how to show stuff — like buttons, charts, or loading spinners. No brain here, just glam.
Controller
When you click a button or submit a form, the Controller takes the input, processes it (usually via the Model), and decides what View to show next.
It glues everything together.
In Web Dev:
- Model = ORM / DB logic
- View = HTML / Templates
- Controller = Express.js, Django views, Rails controllers, etc.
In Android:
- The Controller often ends up being the Activity or Fragment, which gets messy fast — leading to our next pattern.
MVP to the rescue.
MVP evolved from MVC, mostly to make unit testing easier and decouple your UI logic from the Android lifecycle.
Model
Same as MVC — it's your data layer.
View
Still dumb, but now even more hands-off.
It just exposes methods like showUserProfile() or displayError().
It doesn’t decide what to show — just how to render it.
Presenter
The real boss here.
Presenter grabs user input from the View, talks to the Model, and pushes the right data back to the View.
The beauty? View and Presenter talk via interfaces — so you can swap out the View during testing without breaking a sweat.
In Android MVP:
- View = Activity/Fragment (dumbed down)
- Presenter = A testable class with no Android imports
- Model = Repo or data source classes
MVVM – Model View View Model
MVVM is the new-age cool kid, popularized by frameworks like Angular, React (kinda), Vue, and especially in Android with Jetpack libraries.
The key superpower here? Two-way data binding.
That means when your data changes, the UI updates automatically. And when users interact with the UI, the data layer updates in sync — without you manually pushing things around.
Model
Still your data/business logic — just like always.
View
Now even more passive.
Thanks to data binding, it doesn’t even need to call methods on the ViewModel.
It just reacts to data changes.
ViewModel
This is your middle layer.
It holds UI state and handles interaction logic.
Unlike Presenter, it doesn’t tell the View what to do directly — it exposes observable properties, and the View listens.
In Android MVVM:
- View = Activity/Fragment using LiveData or StateFlow
- ViewModel = ViewModel class managing UI state
- Model = Repository pattern + Room/Retrofit/etc.
Bonus: You can reuse the same ViewModel across multiple Views — handy for shared components or screens.
TL;DR – Pick Your Pattern
| Pattern | View Logic | Middle Layer | Communication | Testing Ease | Data Binding |
|---|---|---|---|---|---|
| MVC | In View + Controller | Controller | Tight coupling | ? Meh |  |
| MVP | View interface | Presenter | Interfaces |  Easy | |
| MVVM | View + Binding | ViewModel | Observables | Easy |  |
- MVC: Okay for simple web apps or quick prototypes. Not great for scaling complexity.
- MVP: Great for Android apps where you want testable, decoupled UI and logic.
- MVVM: Ideal when your framework supports data binding or reactive programming. Think Angular, Vue, or Android with Jetpack Compose or XML binding.
In the wild, you’ll see hybrids.
React devs use MVVM-ish logic with hooks and state management.
Vue and Angular lean toward MVVM.
Classic web apps? Still MVC or even MPA chaos.
And Android? MVP ruled for a while, but MVVM is now the go-to thanks to Jetpack ViewModel, LiveData, and Compose.
Final Words
Patterns aren’t rules — they’re guides. Use what fits your team, tooling, and sanity level. And if all else fails, ask yourself:
If the answers don’t make you smile — time to refactor.
I’ve been actively working on a super-convenient tool called LiveAPI.
helps you get all your backend APIs documented in a few minutes
With LiveAPI, you can quickly generate interactive API documentation that allows users to execute APIs directly from the browser.
If you’re tired of manually creating docs for your APIs, this tool might just make your life easier.