While working on enterprise projects, having a solid architecture for your product is critical for market success. Some key benefits of using an architecture pattern are:1. Code maintenance2. Ability to deliver features at a faster rate3. Easier debugging

To that effect there are three core architecture patterns:

• MVC (Model-View-Controller)
• MVP (Model-View-Presenter)
• MVVM (Model-View- ViewModel)

We shall dive in today a bit more into the MVVM architecture pattern.

MVVM stands for Model-View-ViewModel. MVVM was introduced by Microsoft in the early 2000s specifically to simplify event-driven programming. With this pattern, the view reacts to the changes asynchronously.

There are three key benefits over other architecture patterns.

1. It moves the responsibility for state management away from the GUI layer into a separate model
2. Since the ViewModel acts like a black box, simply providing the state to anyone who is interested, unit testing is a lot easier.
3. Serialization and Storage of the model becomes easier, since the model already mirrors what a database entity would look like.

While comparing the three architecture patterns, we can see that:

• In case of MVC, the controller performs a lot of operations. From GUI state management, setting up the GUI itself, API calls, parsing data etc., the controller can become quite a beast. Because of such tight coupling, the controller layer is the least reusable part of the app. Think of the controller as the brain of the app, it decides what happens next.
• In case of MVP, the presenter replaces the controller (well, sort of). The presenter takes over the state management, however the actual GUI setup is left to the view themselves (which is a step up from MVC). This helps in offloading and decoupling some of the responsibility. All communication between the presenter and the view takes places viainterfaces, callbacks or notifiers.

So how do we use MVVM across various platforms? Let’s tackle them one at a time.

Flutter:

The Model: The model layer in Flutter is the same as in iOS and Android. Like the other platforms, the data can be stored either inSqflite,Moor, orObjectBox. The first two storage options are called relational databases (SQL databases). In fact, Moor is build on top of Sqflite, which leads us convert Dart code into sql syntax. ObjectBox is a NoSQL persistance option which supports data sync.The Model can only reflect the raw data, not the characteristics or any features related to the product. This means that the data within the model cannot be manipulated for representation purposes. That responsbility lies with the view itself.

The View: Views in Flutter can be either aStatefulorStatelesswidget. An example for stateful and stateless widget can be viewedhere. Since the view responds according to the gestures or inputs provided by the users, it has no prescribed knowledge of the Model layer. However, it attains the properties of the user behaviors and other data bindings acknowledged within the specified Model and ViewModel.

The ViewModel: In the Flutter world, the ViewModel layer can be initialized via a factory pattern. The views are notified via streams & sinks or by usingChangeNotifiers. The ViewModel also possesses access to the methods, function calls, and other factors that can help to maintain the actual state of the View. Moreover, this access also allows the ViewModel to manipulate or moderate the Model according to the behaviors in the view while triggering its processes.In Flutter, the BLoC pattern is very similar to Model-View-ViewModel. Another way to phrase this would be the following:

BLoC + RxDart = MVVM

Let’s step back a bit here:BLoC (Business Logic Components) can be described as a pattern in which everything within an app is represented by asstream of events. RxDart is reactive functional programming for Dart, based on ReactiveX (Rx).

As you can see, BLoC moves the business logic into a separate layer. This is very similar to a ViewModel. RxDart can then be used for communication between the ViewModel and View via streams (instead of interfaces or change notifiers for example).

Android

The Model: The model package in Android can be anything from aSQLitedatabase, Room, or any third party ORM dependencies like Realm. InMVVM, the model layer is a POJO (plain old java object) class. The package consists of only Java/Kotlin classes without any reference to the Android platform for unit testing.

The View: The view package in Android is made up of either an Activity, Fragment, or a custom View class.

The ViewModel: The ViewModel in Android is designed to store and manage UI-related data in a lifecycle conscious approach. All communication between viewmodel and view is usingLiveData.

iOS

The Model: The model package in iOS is similar to the model layer in Android. The layer is supposed to represent simple POJO data. The data can be stored in either aCoreData instance or Realm database.

The View:  The view package is represented by UIView orUIViewController objects, accompanied by their .xib files or .storyboard files.

The ViewModel: The ViewModel layer in iOS hides all the complexity with regards to networking, data preparation for the View layer and notifiers for model changes.