The LightSwitch Software Stack (Part 2)

Part 2

In this installment of the series we will be looking at the software stack of LightSwitch HTML Client.
LightSwitch Software Stack

The LightSwitch HTML Client architecture is built on the MVVM (Model View ViewModel) pattern which is an adaptation of the MVC (Model View Controller) pattern. These patterns provide for much better separation of concerns and more maintainable code.

The Stack Components

  • Base. This layer provides functionality used by all the other layers. It mostly builds on and uses the fundamental concepts taken from the WinJS library, such as namespaces, classes, events and promise objects.
  • Model. This layer implements loading, parsing and processing of the LightSwitch application model. The model is converted from its original LSML form into a standard JSON representation for quick and easy consumption at application startup.
  • Shared. This layer implements the concept of a business object, which, represents a base for both entities (data) and screens (view models).
  • Data. This layer implements the LightSwitch data concepts, including entities, data services and data workspaces. It depends on the datajs library for underlying communication with the LightSwitch OData service.
  • View Model. This layer implements the LightSwitch view model concepts, including screens and content items. It also implements the view model for the shell, which includes application-wide commands and the LightSwitch navigation model.
  • View. This layer implements the LightSwitch view concepts, including controls, layout primitives and the visualization of the shell. It depends on the jQuery and jQuery Mobile libraries for DOM manipulation and other browser communication.

The layering of the LightSwitch HTML client architecture provides a solid foundation for enterprise applications that are highly maintainable and scalable. I will be reviewing each of the library components individually in subsequent installments of this series.

LightSwitch HTML Client (Part 1)

Part 1

The new path forward?

I have been surveying the landscape recently trying to decide where to spend my professional development time for the next 12 to 18 months. I have shied way from LightSwitch in the past because it was based on Silverlight and XAML and I didn’t think that either of those technologies were worth any investment of my time. Recently I have been encouraged to take another look at LightSwitch in the HTML client version. I have decided to pursue this since it fits directly inline with my desire to master the HTML5 stack.

The following series of articles will chronicle my learning and evaluation experience.

The Overview

LightSwitch HTML Client is a HTML5 and JavaScript based application development “framework” environment for building touch based applications. Using a responsive design philosophy you can develop applications starting with the handheld device and increasing functionality based on the client environment. Using Visual Studio you can point and click your way to a functional application within minutes. I personally have done it in as little as 30 minutes.
LightSwitch Architecture

As you can see from the above graphic the application developer has a variety of options at their finger tips with the promise of new levels of productivity. Substantially gone are the days of spending hours and hours on plumbing code.

I am excited to embark on this journey and hope that you enjoy coming along with me.

Additional Reading

LightSwitch HTML Client Architectural Overview

HTML5 “Stack”

Lately I have been doing a lot of work with what I am calling the HTML5 Stack.  This stack consists of HTML5, CSS3, JavaScript, jQuery and jQueryUI.

I am very impressed with the breadth of capabilities that the stack delivers to the application developer.  From the much improved semantic correctness of HTML5 to the wonderful new additions to css in CSS3, I have been really enjoying the new play ground.

As simple example…

One of the issues a developer faces is when to put up a message and when to take it down.  This seems like a trivial issue but the orchestration makes it sometimes quite complex.  Say we have an error message that we want to place on the web page but the when and how to dispose of that message can get quite messy.

The other day I focused on the issue for a project and found that with a couple of little lines of code the problem just goes away.

The Page

<meta charset="utf-8" />
<link href="css/ui-lightness/jquery-ui-1.10.1.custom.css" rel="stylesheet" /> 	
<link href="css/myCss.css" rel="stylesheet" />
<script type="text/javascript" src="js/jquery-1.9.1.js"></script>
<script type="text/javascript" src="js/jquery-ui-1.10.1.custom.js"></script>

<input id="errorMessage" type="text" value="Yo John" /><a id="lnkClose" onclick="closeErrorMessage()" href="#">x</a>
<input id="showHide" onclick="showErrorMessage('Yo man this is cool', 5000, true)" type="button" value="Show" />


$(function () {

// Show an error message for 5 seconds (1 second = 1000 milliseconds)
showErrorMessage = function (message, duration, IsSticky) {
   if(!IsSticky) {
   else {

closeErrorMessage = function () {

In this example you can now display an error message with a timeout value (1000 = 1 second) or sticky so that the user has to dispose of the error on a case by case basis.

Historically this would have been a task of determining when the event should be shown, when it should be removed, what each of the initiating events would be and on and on. Now it is just show the error set the timeout and move on with the rest of the interaction.

I have decided to spend the next 12 to 18 months really mastering this “stack”. I would be pleased if you would join me on this adventure.