MVVM Deep DivePosted by Itay Herskovits on Jun 24, 2015
Models in a MVVM application sit on top of – and interpret – data from the data storage layer, performing tasks very similar to their counterparts in MVC applications. A model represents a concrete conceptual object, and handles both manipulation of that object and any side effects. This inclusion of side effects – a pattern often followed in MVC applications – is known as a “fat model” approach, as in an application of any significant size a lot of the underlying business logic is broken down into object interactions and performed at the model layer, leaving the intermediary layer to serve primarily as a routing and marshaling mechanism. In MVVM this pattern persists after a fashion, but more often than not a lot object interactions are handled in the ViewModel layer. More on that in a moment.
Again, as in MVC applications, the view layer is specifically focused on presenting data to the user. The primary difference in MVVM is in the level of interaction. In the MVC architecture, views are passive. MVC views take models gathered and interpreted by the controller, then present that data to the user. Manipulation of this data then becomes a series of conversations with the underlying controller, which governs the behavior and response of the web server as the side effects of the UI changes propagate through the system.
MVVM views, on the other hand, are active. Changes in presented data are pushed back down to the model by the ViewModel, which also handles reflecting changes in the underlying data store. This means that changes made to data in the view later has a much more immediate effect on the underlying system, with the ViewModel responding immediately to the changes (rather than waiting for a conversation with the controller).
The ViewModel layer of MVVM replaces the MVC controller in many ways, but performs a larger set of tasks. The ViewModel handles both pulling data from the data store via the model layer and presenting that data in a manner in which the UI can understand. It is a combination of controller, guiding the application model updates, and a presenter, interpreting the data for display to the user (and a prominent element of the Model-View-Presenter, or MVP architecture). The ViewModel is tasked with pulling all of the relevant data for the UI together, as well as handling underlying changes to that data in a way that makes sense to the models manipulating the actual data store itself.
Tying it Back to Angular
The obvious way in which AngularJS enables MVVM architecture is through two-way data binding. With the advent of two-way data binding, updates to the UI are immediately passed through the ViewModel layer to the models themselves, both updating the UI-specific elements and the data store. Furthermore, changes in the underlying models are quickly communicated to the UI, creating a more responsive application that can perform most of its work on the client side. This architecture, when driven by AngularJS, ends up allowing a lot of the business and display logic to move up to the client layer, with the practical upshot being that the data itself is almost completely decoupled from the user interface, with Angular’s two-way data binding handling the task of translating the underlying server data into a type that the UI can use.
The MVVM architecture builds off of its predecessors, the MVC and MVP architectures, using concepts from both and combining the two approaches into a style of application that truly separates the UI from the data driving it. By abstracting and routing data modifications in the ViewModel layer, and by performing the display translations necessary to drive the app’s UI behavior, the ViewModel serves as both controller and presenter, easing the dependence on expensive server calls to drive application state. Through use of Angular’s two-way data binding, changes in the UI can be reflected in the underlying data store much more quickly, and similar changes in the underlying model are rapidly presented to the user. This enables the application developer to truly focus on how data flows through the application, letting the models handle the data itself, and allows an intermediary layer that truly removes the dependence on a highly-intelligent back end.
SIGN UP for free and start creating your app today.