MVVM
What is MVVM?
MVVM or Model-View-ViewModel is an architecture pattern in software development based on Model, View and View-Model, which consist and follow these tree main elements:
- Model: Model refers either to a domain model, which represents real state content (an object-oriented approach), or to the data access layer, which represents content (a data-centric approach).
- View: User Interface or UI (blazor pages in our case).
- ViewModel: the ViewModel layer coordinates operations between the view and the model layer, also, it will invoke operations between the Model layer when it's necessary.
How It Works?
To Understand what is MVVM architecture it's important to understand how it works. In truth, it's the Binding Mechanisms that builds a pattern so efficient to create apps like WPF and Silverlight.
In practice, the Model layer does not communicate with the View nor does the View communicate with the Model. But the View knows the ViewModel and communicates with it through the binding.
That's why the ViewModel layer has a very important function in the stream. After all, it provides the View with presentation logic and coordinates the View's iterations with the Model, in addition to being able to implement validation logic to ensure data consistency.
Benefits:
Understanding what is MVVM Architecture and count on it's benefits as it's very important to the developer. In that sense here's some advantages of it's use:
- Relatively easy to learn;
- Important to the Mobile development;
- Makes it possible to enable a more iterative and exploratory style;
- Lets you simplify unit testing;
- Supports the collaboration team;
- Supports easier code Maintenance;
- MVVM can be used with Swift, Java, Dart (through the Flutter framework) and JavaScript frameworks.
Connecting ViewModels to Views
ViewModels can be connected to views by using the data-binding capabilities of .NET MAUI. There are many approaches that can be used to construct views and ViewModels and associate them at runtime. These approaches fall into two categories, known as view first composition, and ViewModel first composition. Choosing between view first composition and ViewModel first composition is an issue of preference and complexity. However, all approaches share the same aim, which is for the view to have a ViewModel assigned to its BindingContext property.
Subtitle=@BindingContext.TravelBackup.Name?.ToString()
With view first composition the app is conceptually composed of views that connect to the ViewModels they depend on. The primary benefit of this approach is that it makes it easy to construct loosely coupled, unit testable apps because the ViewModels have no dependence on the views themselves. It's also easy to understand the structure of the app by following its visual structure, rather than having to track code execution to understand how classes are created and associated. In addition, view first construction aligns with the Microsoft Maui's navigation system that's responsible for constructing pages when navigation occurs, which makes a ViewModel first composition complex and misaligned with the platform.
With ViewModel first composition, the app is conceptually composed of ViewModels, with a service responsible for locating the view for a ViewModel. ViewModel first composition feels more natural to some developers, since the view creation can be abstracted away, allowing them to focus on the logical non-UI structure of the app. In addition, it allows ViewModels to be created by other view models. However, this approach is often complex, and it can become difficult to understand how the various parts of the app are created and associated.
📝 Important Note: Keep ViewModels and Views independent.
The binding of views to a property in a data source should be the view's principal dependency on its corresponding ViewModel. Specifically, don't reference view types, such as Button and ListView, from ViewModels. By following the principles outlined here, ViewModels can be tested in isolation, therefore reducing the likelihood of software defects by limiting scope.
Example
To Ilustrate the MVVM pattern, let's consider an application that displays a list of books. The model would consist of classes representing books, such as a BookModel.cs, and a BookRepository.cs class that handles data retrieval and storage.
The View would be an activity or fragment that displays the list of books to the user.
The ViewModel would provide the data for the view and handle user interactions. It would contain a bindable property like List< BookModel > that holds the list of books and a method like SearchBooks() or RefreshBooks() to fetch the latest book data from the repository. The ViewModel would update the list of books and notify the view of any changes.
In this example, the view would bind to the ViewModel's property to display the list of books, and the ViewModel would update the model when the user interacts with the list (eg: adding or removing books).
Conclusion
The Model-View-ViewModel (MVVM) pattern helps cleanly separate an application's business and presentation logic from its user interface (UI). Maintaining a clean separation between application logic and the UI helps address numerous development issues and makes an application easier to test, maintain, and evolve. It can also significantly improve code re-use opportunities and allows developers and UI designers to collaborate more easily when developing their respective parts of an app.