MVVM Architecture
Introduction to the MVVM Architecture
Pause for a moment and think about building software applications - like building houses. You will find the entire process very similar.
Both require a location: a piece of land; a location in memory or URL; security: doors under lock and key; login authentication with password credentials; colors; furniture. Most importantly, both require good architecture, otherwise, they will collapse. “We shape our buildings and, thereafter, our buildings shape us.” -Winston Churchill. Depending on our location, security requirements, aesthetics, size of the structure, and most importantly, the function of our structure, we get to select between different architectural patterns. In the same vein, there are different architectural patterns in software development, and depending on all of these factors above, we can also select different software design patterns for our projects. There are a couple of such software design patterns, but we are going to start with the MVVM architecture.
So - What is the MVVM architecture?
MVVM stands for "Model, View, and ViewModel." It is a software design pattern that advocates isolating the application’s main business logic from the views or user interface that presents data. In simple terms, “separating concerns” in your code makes it more loosely coupled, maintainable, and easy to test.
The separate code layers of MVVM are as follows:
Model: Contains the application data source for the application. It composes all the data from the network layer, databases, and services and serves them in an easy way. It should not have any other logic except the one that updates a model. View that view. That will trigger ViewController methods depending on the events such as mouse movements, key presses, etc.
The view can display output in addition to receiving user input. The View should only be used for displaying data and activating events. passed from the ViewController, according to MVVM. Components can be kept reusable and straightforward to test in this fashion.
2. ViewController: This layer has access to the ViewModel and handles the user input. Think of the ViewController as the brain of the View. It has all the view-related logic and owns a reference to the viewmodel. The view is not aware of the viewmodel and it relies on the viewcontroller to pass all necessary data and events. One ViewController can have references to different ViewModels.
MVVM recommends that user input should be handled by the ViewController, which should pass clean and prepared data to the ViewModel.
3. ViewModel: This layer has access to the model and handles business logic. Think of the ViewModel as a producer who does not care who consumes data. It is simply a class and can be easily reused anywhere with UI tailored differently. Every dependency needed by the ViewModel will be injected through the constructor, thus making it easy to test. Whenever the ViewModel updates the model, that change will automatically be reflected back to the View.
