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?
Represents the Data + State + Business logic. It is not tied to the view nor to the
controller, which makes it reusable in many contexts.
Model is the logic associated with the application data. In other words, it is POJO,
API processing classes, a database, and so on.
Binds to observable variables and actions exposed by the View Model. It is possible
for multiple views to bind to a single View Model.
View is actually a layout of the screen, which houses all the widgets for displaying
Responsible for wrapping the model and preparing observable data needed by the view. It
also provides hooks for the view to pass events to the model. An important thing to
keep in mind is that the View Model is not tied to the view.
ViewModel is an object which describes the behavior of View logic depending on the
result of Model work. You can call it a behavior model of View. It can be a rich text
formatting as well as a component visibility control logic or condition display, such
as loading, error, blank screens, etc. Also, it describes the behavior that was
initiated by the user (text input, button pressing, swipe, etc.).
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 ?
It is important to understand that the Model-View-ViewModel pattern extends the Model-View-Controller pattern. It isn’t a dramatic paradigm shift if you are used to MVC. Even though the advantages of MVVM are subtle, they are profound. What are some of the advantages MVVM has over MVC?
The view does not know about the controller it is owned by. Remember that views are supposed to be dumb. They only know how to present the data they are given to the user.
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 controller does not know about the model. This is what separates MVC from MVVM.
The model does not know about the view model it is owned by.
The view model owns the model. When using the Model-View-Controller pattern, the model is usually owned by the controller.
The view controller owns the view. This relationship remains unchanged when using the Model-View-ViewModel pattern.
And, finally, the controller owns the view model. It interacts with the model layer through one or more view models.
→ 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.