MVVM stands for Model View ViewModel, and it’s a design pattern that facilitates a clear separation of concerns between user interface (View), data (Model), and the logic that bridges the two (ViewModel). Here’s a breakdown of what each component does:
Model: This is a blueprint of the data the ViewModel process and pass to the View. The Model is instantiated in the ViewModel.
View: This is the user interface (UI) that the user interacts with. It displays the data prepared by the ViewModel and passes the user’s interaction events to the ViewModel.
ViewModel: This represents the business logic layer; it monitors data, processes data, pass the processed data to the View. The ViewModel also handles interaction events initiated by the user. The ViewModel communicates with the View and Model via binding. Binding creates a two-way connection between a property wrapper that stores data and the view that displays and changes the data. The main idea behind binding is to keep the View in sync with the ViewModel. The ViewModel is the View’s workhorse; without it, the View just sits there and looks pretty. There is a one-to-one relationship between the ViewModel and the View, as in “XYZ View” has a TextField, a List, and a Button, so the ViewModel must have a String property, an Array property, a Bool property, and an action method.
The components of the MVVM design pattern are similar to the components of a typical house. The Model represents the house’s foundation; the View represents the house’s walls and roof; the ViewModel represents the architect, which is the person who uses the Model and View to build a house. As you can see in this simple diagram of the MVVM design pattern, data flows in two directions.
Figure 1-1: Data flow in MVVM components