The MVVM design pattern is similar to the well known MVC pattern in that the M (Model) and V (View) are relatively the same. The only difference resides between the C (Controller) and the VM (View Model).
For a start, let’s consider the classical description of this template and analyze each of its components. Model-View-ViewModel (ie MVVM) is a template of a client application architecture, proposed by John Gossman as an alternative to MVC and MVP patterns when using Data Binding technology. Its concept is to separate data presentation logic from business logic by moving it into particular class for a clear distinction.
So, what does each of the three parts in the title mean?
What does it give us as a result?
Introduced in Google I/O 2015, the Data Binding library helps write declarative layouts and minimize the glue code necessary to bind application logic and layouts.
This approach improves the teamwork convenience, because while one member of the team works with the layout and the stylization of the screen, the other, at the same time, describes the logic of the data acquisition and data processing;
Due to the greater differentiation code becomes more flexible and easy to support, not to mention its readability. Each module is responsible for a specific function only.
A clean separation of different kinds of code should make it easier to go into one or several of those more granular and focused parts and make changes without worrying.
That means you can remain agile and keep moving out to new releases quickly.
With MVVM each piece of code is more granular and if it is implemented right your external and internal dependences are in separate pieces of code from the parts with the core logic that you would like to test.
That makes it a lot easier to write unit tests against a core logic.
Make sure it works right when written and keeps working even when things change in maintenance.
It sometimes overlaps with maintainability, because of the clean separation boundaries and more granular pieces of code.
You have a better chance of making any of those parts more reusable.
It has also the ability to replace or add new pieces of code that do similar things into the right places in the architecture.
The obvious purpose of MVVM pattern is abstraction of the View which reduces the amount of business logic in code-behind. However, following are some other solid advantages −
The ViewModel is easier to unit test than code-behind or event-driven code.
You can test it without awkward UI automation and interaction.
The presentation layer and the logic is loosely coupled.
Why we use ?
There are five rules that you need to know about when using the Model-View-ViewModel pattern in a project. Consider these rules as guidelines. While they can be tweaked or modified, as I show in Mastering Model-View-ViewModel With Swift, they form a solid foundation when applying MVVM in a project.
→ The usage of all patterns is situational, and the benefit (if there is any) always lies in reduced complexity.
→ MVVM guides us how to distribute responsibilities between classes in a GUI application.
→ ViewModel projects the data from the Model into a format that fits the View.
→ For trivial projects MVVM is unnecessary. Using only the View is sufficient.
→ For simple projects, the ViewModel/Model split may be unnecessary, and just using a Model and a View is good enough.
→ Model and ViewModel do not need to exist from the start and can be introduced when they are needed.