One of the principles and patterns which I would like to explore more in this article would be the MV* pattern. Specifically, this article will focus on the Model-View-View-Model (MVVM Pattern).
Firstly, the popular variations of the MV* patterns are 1) Model View Controller, 2) Model View adapter, 3) Model View Presenter and 4) Model-View-View-Model.
MVVM architecture is used to loosen the coupling between components in the code. The Model is responsible for the data that the application needs, the view is responsible for the UI display, and the View-Model orchestrates the interaction of Model and View.
Here is a diagram to illustrate the MVVM interactions:
The view, which is normally handled by a view controller, composes the View-Model. There is a data binding of the View-Model to the view where changes in the data of the view model will render the view to display the new data. Hence, the View-Model is responsible for gathering the Data from the Model, interpreting it and transforming it into data that is able to be displayed on the View.
The View-Model composes the Model and it also acts like an Observer on the Model, while the Model behaves as a domain model for the View-Model. Any changes in the Domain Model will update the View-Model. This can be done by any data-binding means such as Observer Pattern, Pub-Sub Pattern, or the Delegate Pattern where Model invokes modelDidUpdate() method of the View-Model by closure methods passed into the Model.
The benefit of using MVVM is the isolation of components which promotes loose coupling. This makes deployment of isolated components much easier. If the application were to scale up, this allows refactoring to be done easily, such as transforming the code into a microservice architecture (when necessary).
Another benefit of MVVM which comes from the previous point is the increased testability of the code. The View-Model is the component which isolates the presentation logic, while Model isolates the business logic and the view isolates the ui interaction logic. Therefore, the presentation logic, business logic, and ui interaction logic can be easily tested individually and in isolation.
A demonstration of a possible general sequence diagram is as follows:
Let’s use an example to illustrate: a bookmark creation application where the user can create bookmarks.
The user clicks a button to add a bookmark object, triggering the submission of the form. The View will call the handleUserSubmit() method of the ViewModel and pass in the form data inside. The ViewModel converts this data into a domain object readable by the Model, and passes this object into the Model. The model will handle the update of its database with this new object, after which it will call the storageDidUpdate() method of the ViewModel. The ViewModel then updates its presentation data with the new object created. After the method call returns from Model, the ViewModel calls a viewDidUpdate() on the View, which re-renders the view to show the new presentation data. The ViewModel will finally return the method call back to the view. This concludes the sequence diagram.
