MVC design pattern
In the MVC design pattern, it divides the components into three different categories, Model, View, and Controller. You might see the user interaction would be directly on the Controller.
Model
The Model would be the data model to store related data to display. It represents a collection of classes that results either from business logic or data received from outside. In this collection of data classes, they describe the business rules and show how to manipulate and change.
View
The View represents the UIs, which shows on the screen. It usually comes from XML or native Android views. In the MVC pattern, View usually monitors the changes of the data model and reflects these changes, for example, change the display content, change the boundary of view components based on different situations.
Controller
The Controller is in charge of processing user interactions. It usually passes the user requests to View to generate correct results and save to Model. In the meantime, it triggers the data update from the Model to View.
In Android, the MVC design pattern is prevalent and would be this first recommendation for the beginner. The pro would be that you can write the business logic into Controllers along with related Data Model to control the specific View components directly. It would be very convenient to see everything in the same place, but the drawback would be the Controllers become too large to maintain.
MVP design pattern
To solve some drawbacks in the MVC pattern, for example, hard to write the test cases, the super large controller code, the MVP comes up, and try to bring a new relationship between Model, View, and Controller. It derives from the MVC design pattern, where it replaces the Controller by the Presenter. This pattern divides the whole application into three major parts.
Model
The Model is almost the same as the Model in the MVC design pattern. It represents a set of data classes where you can save and manipulate the results from user interactions. In the meantime, you can also define the business rules or the related actions in the Model.
View
The View components come from XML or native Android UI components, for example, Activities, Fragments, and Views. In the View component, it doesn’t contain any operation logic. It’s only responsible for showing the data from the Model.
Presenter
The Presenter would be the bridge between the View and the Model. When a View receives the user interactions, it passes the request to the Presenter via a pre-defined interface in the Contract. After receiving the request from the View, the Presenter would process the request and save the final result into the Model. In the meantime, once a Model changes, it would notice the Presenter. Then the Presenter would also pass the changes to the View for rendering. The pro part of MVP design pattern is pretty obvious. Because of isolation between View and the Model by the Presenter, you can easily create a mock instance for the View and the Model. You can also easily create unit tests for these components. Due to the interface definitions, you can easily replace the different implementation of these three components. The biggest drawback is that a Presenter would become too complicated because of the increase in business logic. That would be a cost to maintain a complicated Presenter.
MVVM design pattern
What problem does the MVVM design pattern try to solve, which we encounter in the MVP design pattern? The answer would be the tight coupling. You might see the relationship diagram above, which shows that every activity/fragment would have its presenter. When the complexity of a View rises, then the Presenter would become more complicated and harder handling.
Back to the MVVM, Google has officially listed this as a recommendation architecture for the developers. Check the model diagram below.
Model
The Model concept here is the same as in MVC and MVP models.
View
The View concept here is the same as in MVC and MVP models.
View Model
What does a View Model do? It maintains the state for Views, which needs to change the content display based on the state change. There is a multiple to one relationship between View and ViewModel. It doesn’t like the MVP model. In the MVP model, every view (activity/fragment/view) should have its presenter. This hard binding relationship would cause a little bit harder for writing the unit tests. But in the MVVM, that’s no longer an issue because you can use subscription to get data from the View Model. So, the MVVM provides an optimized observer pattern for the developers.
That’s the very high-level overview of these three patterns. Happy coding, enjoy!
Reference
[1]ViewModel Overview | Android Developers
[2]Why to choose MVVM over MVP — Android Architecture - AndroidPub