Patterns

Interestingly enough, most of the patterns we have started applying have been around for quite a while. The Model View Controller (MVC) pattern is a great example of this.

The purpose of MVC is to decouple the elements in the frontend and create a better isolated focus on these different concerns. Basically, what one has is a controller that governs the actions that are allowed to be performed for a particular feature of your application. The actions can return a result in the form of either data or concrete new views to navigate to. The controller is responsible for holding and providing any state to the views through the actions it exposes. By state, we often think of the model and often the data comes from a database, either directly exposed or adapted into a view-specific model that suits the view better than the raw data from the database. The relationship between model, controller, view, and the user is well summarized in the following diagram:

A representation of how the artifacts make up MVC (don't forget there is a user that will interact with all of these artifacts)

With this approach, you separate out the presentation aspect of the business logic into the controller. The controller then has a relationship with other subsystems that knows the other aspects of the business logic in a better manner, allowing the controller to only focus on the logic that is specific to the presentation and not on any concrete business logic but more on the presentation aspect of any business logic. This decouples it from the underlying subsystem and thus more specialized. The view now has to concern itself with only view-related things, which are typically HTML and CSS for web applications. The model, either a concrete model from the database or adapted for the view, is fetched from whatever data source you have.

Extending on the promise of decoupling in the frontend, we get something called Model View ViewModel (short for MVVM).

This is a design pattern for the frontend based largely on MVC, but it takes it a bit further in terms of decoupling. From this, Microsoft created a specialization that happened to be MVVM.

The ViewModel is a key player in this that holds the state and behavior needed for your feature to be able to do its job, without it knowing about the view. The view will then be observing the ViewModel for any changes it might get and utilize any behaviors it exposes. In the ViewModel, we keep the state, and as with MVC, the state is in the form of a model that could be a direct model coming from your data source or an adapted model more fine-tuned for the purpose of the frontend.

The additional decoupling, which this model represents, lies within the fact that the ViewModel has no clue to any view, and in fact should be blissfully unaware that it is being used in a view. This makes the code even more focused and it opens an opportunity of being able to swap out the view at any given time or even reuse the same ViewModel with its logic and state for second view.

The relationship between the model, view, viewmodel, and the user is summarized in the following diagram:

The artefacts that make up MVVM. As a reminder, don't forget that the user interacts with these artifacts through the view.