It resolves the problem of having a dependent View by using Presenter as a communication channel between Model and View. |
This architecture pattern is more event-driven as it uses data binding and thus makes easy separation of core business logic from the View. |
The one-to-one relationship exists between the Presenter and the View. |
Multiple View can be mapped with single ViewModel. |
In this, observables are not needed as a Presenter layer. |
In this, observables are needed due to the absence of Presenter layer. |
User interface is used more in MVP. |
There is no user interface in MVVM. |
The architecture is heavyweight. |
The architecture is lightweight as compared to MVP. |
Testing is done easily as business logic and UI are separate. |
Testing is difficult as Business logic and UI are not separate. |
In this case, debugging is easy. |
In this case, debugging is not easy. |
The Presenter has knowledge about the View. |
ViewModel has no reference to the View. |
Model layer returns the response of the user’s input to the Presenter which forwards it to View. |
After performing operations according to the user’s input, the Model layer returns the response to the ViewModel. |
Presenter handles the application flow and the View is the actual application. |
ViewModel is the actual application and View is the interface for the user in order to interact with the app. |
The project file will contain more classes as well as code. |
The Project file will contain more classes but less code per class. |
Maintenance is not ensured in the architecture. |
Maintenance of the layers is very good. |
Ideal for simple and complex applications. |
Not ideal for small-scale projects. |
Core testing is not done in MVP |
Core testing is done in MVVM. |
Easy to carry out Unit testing but a tight bond of View and Presenter can make it slightly difficult. |
Unit testability is highest in this architecture. |
It does not work well with android applications or software. |
It works extremely well with android applications or software. |