Model-View-View-ViewModel (i.e. MVVM) is a client application architecture pattern that was proposed by John Gossman as an alternative to the MVC and MVP patterns when using Data Binding technology. Its concept is to separate the data presentation logic from the business logic by putting it in a separate class for a clearer distinction.
Now let’s understand what each of the three parts in the name means:
- Model is the logic that is associated with the application data.
- In other words, it is POJO, classes for working with API, database, etc.
- View – actually, this is the layout of the screen, where all the necessary widgets for displaying information are located.
ViewModel – an object that describes the logic of View behavior depending on the result of Model. You can call it a model of View behavior. It can be either text formatting, or the logic of controlling the visibility of components or displaying states such as loading, error, blank screens, etc. It also describes behavior that has been initiated by the user (text input, button click, swipe, etc.)
So what does this give us in the end?
- Flexibility of development. This approach increases the convenience of working in a team, because while one team member is working on the layout and styling of the screen, another one is describing the logic of data acquisition and processing;
- Testing. This structure simplifies writing tests and the process of creating mock-objects. Also, in most cases there is no need in automated UI-testing, because you can wrap unit-tests with ViewModel itself;
- Logic delimitation. Due to greater delineation, the code becomes more flexible and easier to maintain, not to mention readable. Each module is responsible for its specific function and only that.
Since nothing is perfect, there are disadvantages:
- For smaller projects, this approach may not be justified.
- If the data binding logic is too complex – it will be a bit more difficult to debug the application.