Home > Architecture, Programming > Structuring presentation logic using UI Architectural patterns

Structuring presentation logic using UI Architectural patterns

This post is part of a series of posts on Client-Side Web Application Development using JavaScript.


No discussion about UI Architectural patterns is complete without reading / linking to Martin Fowler’s GUI Architectures & Michael Feather’s The Humble Dialog Box. I will quote extensively from Fowler’s work here, to drive point. If you know MVC & Presentation Model (or MVVM) really well, You can jump directly to the MVC vs. MVVM section

Separation of Concerns

These UI Architectural patterns are all about Separation of Concerns and having more maintainable code – Divide and Conquer

Model View Controller (MVC)

  • In MVC, the domain element is referred to as the model. Model objects are completely ignorant of the UI.
  • Make a strong separation between presentation (view & controller) and domain (model) –Separated Presentation.
  • Divide GUI widgets into a controller (for reacting to user stimulus) and view (for displaying the state of the model). Controller and view should (mostly) not communicate directly but through the model.
  • Have views (and controllers) observe the model to allow multiple widgets to update without needed to communicate directly – Observer Synchronization.

Examples of Javascript Frameworks / libraries which help you with structuring your application based on MVC pattern- Backbone Core, Ember.js, Spine, CanJS

Model-View-View Model

(Presentation Model / MVVM)

The essence of a Presentation Model is of a fully self-contained class that represents all the data and behavior of the UI window, but without any of the controls used to render that UI on the screen. A view then simply projects the state of the presentation model onto the glass.

To do this the Presentation Model will have data fields for all the dynamic information of the view. This won’t just include the contents of controls, but also things like whether or not they are enabled. In general the Presentation Model does not need to hold all of this control state (which would be lot) but any state that may change during the interaction of the user. So if a field is always enabled, there won’t be extra data for its state in the Presentation Model.

Since the Presentation Model contains data that the view needs to display the controls you need to synchronize the Presentation Model with the view. This synchronization usually needs to be tighter than synchronization with the domain – screen synchronization is not sufficient, you’ll need field or key synchronization.

Presentation Model is not a GUI friendly facade to a specific domain object. Instead it is easier to consider Presentation Model as an abstract of the view that is not dependent on a specific GUI framework.


Examples of JavaScript Frameworks / libraries which help you with structuring your application based on MVC pattern – Knockout, Knockback, Kendo UI MVVM (Commercial).

Not all the JavaScript frameworks implement MVC in the strict small talk MVC sense, not even they implement it in the struts sense. They improvise it for the JavaScript scenario. Most of them agree on Separated Presentation and have Model & View. Some of them do not have controllers. Some call controllers as routers. Some implement controller functionality in views. In general all these are variations over MVC – MV*. Model View Whatever – MVW is another term that you would see being thrown around. [from Journey through the JavaScript MVC Jungle]



  • MVC is about separating business logic (Model) from the presentation logic (View and Controller) – Separation of Concerns
  • It opens up the possibility of having multiple presentations technologies on the same model.

MVVM / Presentation Model

While MVC addressed separation of Business Concerns from that of the Presentation, It did not focus much on Presentation Logic. The Presentation Logic in modern applications is significantly complex. Presentation Model puts additional emphasis on organizing presentation logic (which was just a high level guidance in original MVC – Controllers handle user input and View handle display & display logic. In much of the modern UI Toolkit implementations User Input is sucked into the toolkit itself).

The move to Presentation Model came when the presentation logic in the views (and controllers) became more complex and testability of that  logic became a primary concern. Read the Humble Dialog Box article if you haven’t read it. So Presentation Model is all about moving the presentation logic from the View to the View Models (not as is but in an abstract way that is UI framework independent and becomes unit testable) so that the View becomes really dumb / humble.

But it does not come free, along with moving the Presentation Logic from the view we also moved the Presentation State from the View and the View now needs to synchronize with that. This synchronization can be a pain in environments that do not support data-binding.

  • MVVM is about separating business logic (Model) from the presentation logic (View and View Model) – Separation of Concerns
  • But it also addresses other concerns,
    • Having near zero presentation logic & state in the views by moving them to view models
    • Having a view model that is a presentation technology agnostic – UI platform-independent abstraction of a View – Josh Smith’s MSDN Article on MVVM
    • Having testable presentation logic in view models

    MVVM makes much more sense if

  • You are towards near zero presentation logic
  • You are towards Unit Testable presentation logic
  • You are towards two-way data-binding and have a presentation technology that supports it

Some people hate data-binding and its natural for them to use MVC.


If you’re writing an application that will likely only be communicating with an API or back-end data service, where much of the heavy lifting for viewing or manipulating that data will be occurring in the browser, you may find a JavaScript MV* framework useful

If, however, you’re building an application that still relies on the server for most of the heavy-lifting of Views/pages and you’re just using a little JavaScript or jQuery to make things a little more interactive, an MV framework may be overkill. 

from http://coding.smashingmagazine.com/2012/07/27/journey-through-the-javascript-mvc-jungle/

Use MVVM if possible. If you are not comfortable with it use MVC for now but keep an eye on JavaScript MVVM frameworks, they may become a standard in the future.

  • I am biased towards MVVM and all for two way data binding (I also happen to have worked on Windows Presentation Foundation – WPF). So it is a personal preference.
  • The next version of EcmaScript (the standard for JavaScript) code named Harmony (ES-Harmony) will have better support for observable properties (VB / .NET style properties with getter and setter) and more future browsers will support HTML5 data binding attributes (data-* attributes). Both of these future directions can make data binding easier with html5 & JavaScript.

Reading List

GUI Architectures

The Humble Dialog Box.

Presentation Model



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: