Back to blog home page

MVVM Deep Dive

Posted by on Jun 24, 2015

One of the key advantages of AngularJS’ implementation of two-way data binding is that it enables a true implementation of the Model-View-ViewModel (MVVM) pattern. The MVVM pattern originated as an architectural approach for Microsoft’s WPF framework, but has since evolved into a more common web-development paradigm driven by the proliferation of JavaScript frameworks. As it is focused on truly separating the user interface from the underlying data and logic, it is in many ways similar to the MVC architecture we have already discussed. However, there are a few crucial differences that make the MVVM architecture a unique selling point of frameworks like AngularJS. Below we’ll look deep into the thought process behind MVVM, and see what AngularJS provides us for implementing this architecture in a web application.

Model

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.

View

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).

ViewModel

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.

Conclusion

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.