Definition “Model View ViewModel ” What does MVVM mean?
Model-View-ViewModel (MVVM) is an architectural pattern or pattern from software development. The primary goal is the strict separation between graphical interface representation, presentation logic and business logic
In the MVVM pattern, the view model isolates the view from the model, so that the model can be further developed independently of the view.
MVVM is an architectural pattern that can be used to implement a clear separation between business logic and interface in complex projects. To put it simply, one should try to separate different functionalities cleanly from each other during programming, which belong together technically, but are located on different layers of the program.
Accordingly, the display of data on the visible surface must, for example, be separate from the logic that invisibly regulates data access in the background. MVVM was developed by Microsoft and is a variation of the “Model View Controller” pattern or the Model View Presenter (MVP) pattern.
Functional separation of data access and display
The pattern provides for the logic to be decomposed into three components: Model, View and ViewModel.
The model takes on tasks related to data storage. For example, it can request data from a data source, abstract data in the sense of the application, or validate data. The model provides data to the application or receives data for transfer to other services, for example, for saving to a database. It is typical that classes from the model work together with other technologies that take over the access and storage of data, e.g. services.
The view has only the graphical representation on the surface as its task. It therefore represents information and is responsible for the appearance of the user interface. To do this, it uses the information that is prepared and made available in the ViewModel. The source code of the view contains above all the structures that are necessary to display the desired information. It is possible that the view also contains small sections of code that directly influences the display of the information, because, for example, the purely structural preparation is not sufficient for the desired presentation. In addition, the View can communicate changes to the ViewModel, e.g. when a user clicks or writes something.
The ViewModel builds a bridge between Model and View. This is the logic that is needed for the presentation of the data on the surface. The logic listens to the user’s input and, if necessary, can execute the corresponding presentation logic. It requests the data that the view needs for the display or transmits information from the interface to the model where the business logic takes place. The ViewModel can also pass new or changed information to the view at runtime and thus ensure that the displayed data is always up-to-date.
Advantages of MVVM
With clean implementation, the MVVM architecture pattern offers certain advantages for the development of complex applications.
Interchangeable and independent components
View and ViewModel can be exchanged or changed without ever having to touch the model. The basic functions for data access remain untouched until you really have to intervene specifically at this point. This is convenient because the preparation and display of information can be optimized or completely renewed as desired, while the underlying functionality remains unchanged. Conversely, the business logic can be worked on without necessarily having to change the interface.
There is also the option to create different views for a ViewModel with little effort, e.g. to realize different views. Instead of using several views and ViewModels, it is only necessary to create the representation of the interface in different variants.
Testing complex systems as one large unit is complicated and unreliable as the only test method. The logics for surface and data storage are already neatly separated from each other by MVVM anyway. This makes it much easier to carry out more detailed tests. For example, you can view the ViewModel completely detached from View and Model. You do not have to try to cover all scenarios on the surface, but can work with clearly defined unit tests in each module. Thus, with less effort and section by section, it can be checked whether everything works as desired from a technical point of view.
Since the interface and business logic take place in separate modules, developers and UI designers can work independently on the same component if necessary. While the programmer is busy with Model and ViewModel, the UI designer can prepare the graphical interface undisturbed. View and ViewModel can be connected after completion.
Working with MVVM is a bit more complex, especially in the area of data binding and communication between the components. Also, MVVM only works well if the separation is really clean and some things do not get into the wrong component for convenience, e.g. presentation logic in the view.