MVP vs MVVM

For mobile application development, developers mostly go with MVC architecture. This is one of the simplest architectures that is used in software development, but there are alternatives to MVC too. There exist other architectures like Clean Architecture, MVP, MVVM, etc. In Android, MVVM and MVP are recommended architectures to adopt.
As developers, the first question that comes to mind is which architecture to start applying. Will the architecture make my code scalable and maintainable? Since MVCs have already been written about in many blogs and articles, let’s take a look at the others:
What is an MVP ?
MVP — Model View Presenter.
Model — Models contain data. Models are only gateways to business logic. They simply store the data. Think of Models as real world objects. For example, a car or a mobile can be a Model. So taking the car model example, this model will have properties such as name, type, created on, etc.
Presenter — The Presenter layer handles the logic. Presenter layers act as middle-men.
View — View handles the UI component. It takes controls of views properties and it is responsible for displaying the data.
- The interaction between View and data is done via the Presenter. View makes a call to Presenter for the data and the Presenter applies the query for data and also applies the necessary logic to then give back data to view to be displayed on the screen.
- The Presenter layer interacts with the service layer (fetching data from the server over the internet) and the database layer for data to be shown in view.
- The Presenter is responsible for calling the Model layer for data, usually at the request of its View and receive that data via callbacks.
- Any long process (such as fetching data from the server, storing it in the local database, etc) should be done in a background thread so that the app doesn’t crash.
- View is dumb and doesn’t contain business logic. It simply shows the data.
- When some action is performed on View, View calls the presenter and presenter decides what do next. Example view will call presenter methods like onSubmitClick(String message), onNextClicked(String name),etc and then presenter would call view methods like : showError(String message), showCars(List<T> cars).

What is an MVVM ?
MVVM — Model View ViewModel (data binding) is highly recommended for use. It is divided into 3 layers — Model, View and ViewModel.
Model — Models contain data. Models are only gateways to business logic. They simply store the data.
View — View handles the UI component. It takes control of View properties and is responsible for displaying the data. View takes care of the following actions:
- Showing error and successful messages.
- Starting activities.
- Event listeners.
- Giving control to ViewModel for the event action taken.
- As it can have application context, all operations related to application context need to be done in View. Eg: startActivity(), inflateLayout(), etc.
ViewModel — ViewModel should have all information required to display the View. Multiple Views can share a single View model. This helps in reusing the functionality for a different layout.
- If data binding is applied then it contains data which is bound to the view(xml).
- Whenever there is change in data, it automatically notifies the View rather than calling it explicitly using data binding.
- View validation and any changes in properties of view is taken care by it.
- It is also responsible for giving callbacks to the View.

Benefits of using architecture
Tightly coupled code is not easy to maintain and scalability is an issue. But when the business layer is different from the UI, it becomes easy to reuse and maintain the code.
- If you implement MVVM properly, then you can easily create layers and wrappers around the View, which allows you to change the View without impacting business logic.
- This becomes very useful while writing test cases for the View classes and Presenter classes.
- It helps to separate the layers. In MVC, Activity/Fragment keeps the logic, whereas in this case business logic moves to the Presenter. You can have different layers — database and service layers which can be invoked by the Presenter layer. It helps to keep the codebase clean and separate logic from the UI and move logics to database/service/presenter layer. MVP pattern helps in separation of layers and facilitates unit testing.
Why MVVM?
- Separation between User Interface (Views) and Logical Code (ViewModel/Model) is possible.
- MVVM helps in writing UI test cases using Expresso.
- Ease of maintenance and ability to add changes to your codebase is high.
Why MVP?
In the MVP design pattern, the Presenter is responsible for manipulating the Model and updating the View. The Presenter can be unit-tested by mocking the View and the Model. This gives the developer the ability to test different behaviours i.e functionality tests.
Want to work with the awesome Tech team at UpGrad? Check out the positions now open!