Journey Through MVC Architecture Using KnockoutJS

Up until two years ago, I had not idea of any MVC framework; however I knew that my front end development needed organization and structure. My first introduction to an MVC framework was JavaScriptMVC. I played around with it and implemented some of its organizational structure in the project I was working on. My second dive into the JavaScript MVC jungle was a 5 minute lightning presentation by Tim Branyen on Backbone at a meetup (if you know Tim and know how fast he can talk, then you will understand when I say there was a vast amount of information in that 5 minute talk). Coming out of that meetup and walking back with a fellow developer, he told me about KnockoutJS. I was eager to try out some of these frameworks on my next project.

The opportunity came up on my next project with MIT where I inherited a website in dire need of structure and organization. This is where my previous research paid off and I choose KnockoutJS to implement and this is what I learned in the process.

What does MVC mean for Front End Development?

When it comes to development, there are several design patterns and the MV* frameworks are examples of one design pattern. There is the all familiar MVC and there is also MVP and MVVM. Nevertheless, all these frameworks have similar baseline structures with minor differences. For simplicity sake, I will concentrate on MVC framework.

“The idea behind [MVC] is to make a clear division between domain objects that model our perception of the real world and presentation objects that are the UI elements we see on the screen…Domain objects should be completely self contained and work without reference to the presentation, they should also be able to support multiple presentation, possibly simultaneously.”

Martin Fowler

  • Model: domain or structural objects representing the application’s state. If your application has data or logic, then you need a model. Your application can be broken down into different models for example users, photos, experiments, classrooms, etc… These models contain a state that will be displayed to the user  in the “View”.
  • View: Observes the model’s state and generates output for the user. This is generally the part of the application the user sees and it is our way of displaying the model to the user through markup and templates.
  • Controller: Translates the user input into operations on the model. As the user interacts in the “View”, the controller captures the interaction and updates the state of the “Model”. Subsequently the implementation of an observer pattern will update the “View” with the latest state of the “Model”.

The frameworks that support the MV* structure are numerous, here are a few options:

When should one choose one of these frameworks? Some people think that if your application reaches certain level of complexity, you should be using one these frameworks. I am of the humble opinion that, aside from informational websites that can be written with WordPress, Drupal, or simple HTML (and no backend or database interaction), should adopt an MV* framework. Many sites may start as simple applications but your simple application especially if successful will become complex and at that point it may be too late and more difficult to implement these frameworks.

One of the best tools to evaluate the different types of MVC frameworks is Addy Osmani’s TODO MVC site. This site shows you how to implement a simple todo application using different frameworks.

Benefits of Using a MV* Framework

  • Separation of concerns: This is the main goal of an MVC framework, to be able to separate the different working areas of the site into Model, View, and Controller.
  • Easier overall maintenance
  • Side by side development: This is a  benefactor of the separation of concerns which will allow developers to work side by side on different parts of the application with reduced over-stepping on each others work.
  • Organization: If you have had to trudge through as much spaghetti code as I have, then this will be your favorite benefit of these frameworks.

One thing to consider is that these frameworks are not a substitute for good JavaScript development. These frameworks will enhance your code, it could enhance good code or bad code; you pick.

MVVM

MVVM was originally defined by Microsoft for use with Windows Presentation Foundation (WPF) and Silverlight, having been officially announced in 2005 by John Grossman in a blog post about Avalon (the codename for WPF). It also found some popularity in the Adobe Flex community as an alternative to simply using MVC. In the MVVM framework, the “Model” and the “View” follow the definitions as stated above. The “ViewModel”, as the name suggests, is the go between the View and the Model. The ViewModel can be considered a specialized Controller that acts as a data converter. It changes Model information into View information, passing commands from the View to the Model. For example, the Model may contain a boolean value like isAvailable, it is up to the ViewModel to interpret that and display the correct information to the user.

Benefits of KnockoutJS

  • Declarative bindings: Easily associate DOM elements with model data using a concise, readable syntax
  • Automatic UI refresh: When your data model’s state changes, your UI updates automatically
  • Dependency tracking: Implicitly set up chains of relationships between model data, to transform and combine it
  • Templating: Quickly generate sophisticated, nested UIs as a function of your model data

Next Steps

In order to better understand KnockoutJS, I have created a tutorial creating a Flickr app. Creating this app will help in better understanding of the KnockoutJS.

References