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
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 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 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
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.
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
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 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
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
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
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
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 concept here is the same as in
View concept here is the same as in
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
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!