MVVM Pattern — Introduction
Why do we need architecture patterns?
Developing a software project without architecture or design patterns can be compared to a building without foundations.
In the beginning, most developers or managers won't consider architecture as a faster approach. However, they‘ll start realizing that their traditional approach has turned out to be a dead end. It is too late to add architecture or patterns to such a code. When the project size starts to increase, many problems pop up and start affecting the project. A well-chosen architecture saves a lot of problems with maintenance and development.
MVC - Expectation vs Reality:
MVC (Model-View-Controller) is Apple’s recommended architectural pattern. This design pattern assigns objects in an application one of three roles: model, view, or controller and it also defines the way objects communicate with each other. The interaction between objects in the MVC is depicted in the following figure:
In iOS & macOS app development, due to the introduction of the ViewController, most developers misunderstood and started stubbing all the controller logic and view logic in the viewController itself. Since the controller became a massive view controller, mocking and testing the code became a tedious task.
There are other patterns as well like MVP, MVVM, VIPER etc., but we’ll focus on MVVM in this article.
MVVM:
Model-View-ViewModel is a structural design pattern that facilitates the separation of business and UI logic.
The data flow in MVVM is shown below:
Model: This layer contains the data consumed by the application. It contains a set of structs or classes that define the information that would be used (and eventually rendered by a view). They could be eventually recovered through an API or a local DB or generated by the app itself.
View: This layer consists of visual elements. In the View, we initialize UI controls (such as labels, buttons, tables), set up the layout, perform animations, etc. In iOS, it is inseparable from view controllers.
ViewModel: This layer is responsible for business logic, which transforms model information into values that can be displayed on a view and serve as a bridge between the model and view.
Example:
Let’s create a profile view with the MVVM design pattern. Since its an introductory post we’ll keep things very simple.
- Model
2. View
3. ViewModel
Here we have a simple user model which is used to render the Profile view. We’ll focus on updating the view with changes in the Model and update the model with user events in the upcoming posts.
Advantages of MVVM:
Separation of concerns - It makes the view controller simpler by moving a lot of business logic out of it.
Ease of testing - A view model is much easier to test than a view controller. You end up testing business logic regardless of the effects of view implementations.
Transparent communication- It offers a transparent interface to the ViewController that interacts with the model and view layers. This results in transparent communication between the layers of the applications.
What did we learn?
In this post, we learnt about:
- The need for architecture and design pattern
- The problem with MVC
- Introduction to MVVM with an example.
- Advantages of MVVM
