MVC, MVP, and MVVM Architecture Pattern from my 6 years of experience in Mobile apps Development
In Product Development, Software engineers work with requirements and code. From the requirements, engineers split it into smaller pieces of problems and solve them by code.
It’s ok to write down all source code in 1 file (In Android they’re Activity and Fragment Classes) when the project is small and has fewer features. Problems come when the Product Team wants to expand the app with more requirements and features. Engineers will get stuck to keeping the source code stable, and maintainable while adding more features.
Software Architecture Pattern comes to solve this problem, by modularizing the codebase into separated code parts. Each part has the responsibility itself and doesn’t impact others’ business logic.
MVC
This seems the oldest Android App Architecture Pattern in history. MVC split the codebase into 3 layers named: Model, View, and Controller.
Model
- This layer stores app data.
- Responsible for handling app logic calculation, connecting databases, and handling network APIs …
- The Model layer can contain several classes to do their task, but not anything related to UI. This layer is pure logic calculation.
View
- The representation of data from the Model layer
- The UI to display for User Experience.
- Receive events from user interaction and forward them to Controller.
Controller
- The core layer coordinates the app’s flow.
- Fetch data from Model to setup View
- Receive events from View, then demands Model layer to do the right task.
Pros
- The Model and View layers are separate from the Controller.
- The Model’s code doesn’t relate to the Android source code
- The View’s code is pretty dumb, it only updates on demand via Controller
- This increase the testability of the Model & View if the engineers follow the single responsibility principle → let the View dumb and update on demand via Controller and place the domain logic inside the Model layer.
Cons
- The Controller in this model represents by Activity, and Fragment classes. This means the Controller is mixed between View and Model code. When you want to update the View or Model, the controller will be impacted and need to be updated.
- Through development time, the Controller’s code will be expanded and increase its complexity. This can make the project lose control.
MVP
MVP a.k.a Model — View — Presenter Software Architecture Pattern breaks the Controller into the real View and the Presenter. In this pattern, Activity and Fragment are treated as the View layer. The Presenter layer contains pure logic to interact with the Model layer and demands the View layer to display as expected.
Model
- Same as Model in MVC
View
- Same as View in MVC
- The only change is we treat Activity, and Fragment as View. Not Controller anymore
Presenter
- Same as Controller in MVC
- The only change is Presenter has no reference to Android APIs
In MVP View and Presenter have reference to each other. To implement this idea but still keep the Presenter clean with no reference to Android APIs, we need a Contract Interface to define the supported APIs between View and Presenter.
Contract Interface contains the pre-defined APIs, this allows the View or Presenter to implement, execute, and be easy for mocking/testing in Development.
Pros
- Solve the problem of MVC Pattern, destroy the reference to Android APIs in Controller (Presenter now)
- The codebase is split to separate parts and can be easy to test, mock
Cons
- Engineers have to 100% follow the pattern to prevent mixed code logic → this is the reason for technical debts
MVVM
We can say MVVM is an upgrade of MVP, it inherits the founding idea of MVP that keep the logic of View and Model separated while the Presenter’s role is played by the ViewModel.
Besides, the Android ViewModel fixed the drawbacks of the Presenter in Lifecycle Handling, by making ViewModel’s initialization depend on the View’s lifecycle (Activities and Fragments) → Now, we can easier to handle data, streams, and logic flow by ViewModel when dealing with Activity or Fragment Lifecycle.
Important Infos, ViewModel x LiveData x DataBinding is a good practice for MVVM Android App Development. I think we may discuss about this in more detail in another post.
Model
- Same as Model in MVP
View
- Same as View in MVP
- View in MVVM is lazier than MVP or MVC because they just observe the changes from ViewModel and update. ViewModel doesn’t need to proactively call to ask View to update like Presenter in MVP
ViewModel
- The ViewModel itself is just a Data Holder class depending on View’s Lifecycle, they don’t contain the observable data stream. To maximize the power of ViewModel we’ll use it with LiveData — a class that represents data as an observable object → Activity or Fragment now can observe on LiveData to listen to the value change events
- Contains and exposes observable data streams related to View’s displaying using LiveData
- Receive the demands from View (user interaction or system changes) then process logic or forward it to the Model layer if needed.
Pros
- Unit Testing is easier in MVVM. Separated parts have permission and scope itself, Software Engineers can easy to maintain or replace a module when needed.
Cons
- ViewModel and LiveData are lifecycle awareness, Software Engineers need to be careful to implement UI updates via observing on LiveData.
- Discipline! Discipline! Discipline! Strictly required to keep the codebase clean, and less chance to create tech debts as much possible.
Why MVP is for beginners? Why not MVC or MVVM or sth else?
- Beginners should start with a small project, which best fit with MVC or MVP.
- MVP splits the codebase into separate parts that are not related to each other. The Model and Presenter do their tasks and don’t know anything about View → MVP is advantaged than MVC
- MVVM is an upgrade of MVP. To completely understand the MVVM we need to work fine with MVP (based on my experience)
In case you reach this line, I hope this post can be helpful to you.
Happy coding!
