Exploring the circuit

This chapter, ‘Exploring the circuit’, takes the reader on an investigational journey to help understand the development tedium that LightSwitch enlightens, vocabulary used in the LightSwitch community, the application structure and the IDE.  This chapter focuses more on LightSwitch in general, not on creating LightSwitch mobile apps exclusively.

What is LightSwitch?

LightSwitch does not come with an official definition, and because of how much it has grown since its first release and the broad array of software development challenges that it can help with, it is not an easy task to formulate a succinct definition either.

I’m willing to try though…

LightSwitch is a combination of frameworks and integrated tooling that aids professional developers on their quest to build highly specialized LOB applications (stand-alone or as part of a bigger ecosystem) in rapid release cycles without having to compromise on interoperability or flexibility (by enforcing industry proven standards and patterns and promoting scalable architectural designs).

That is a mouthful indeed, allow me to substantiate it by looking at what ‘LOB applications’ really are and how LightSwitch is designed to help in building them.   (See notes 3 and 4)

What are LOB applications?

Line-of-business applications are applications that are written to be privately used by a particular company.  Estimates say that about 90% of the total quantity of all software written today are LOB applications.  Each LOB app is unique to the business process, the company culture and geographical location where it is used.  However, there are quite some common denominators. 

Most LOB applications model the real world in some domain-specific software structures called models (pun intended).  LightSwitch developers refer to these models as ‘Entities’.  Entities need to be persisted, so that they can be reused between runs, shared between different end users or even exchanged between different applications.  Some LOB applications have a set of data so unique that it can be stored in a data store that is unique to the application, called the ‘Intrinsic data source’.  Often though, LOB applications are part of a larger ecosystem and will reuse already existing data sources.

‘Data source’ doesn’t necessarily equal a ‘database ‘. Entities can be stored in and retrieved from a variety of sources: a new or existing database (from another active or legacy LOB application), web services (think about company SharePoint lists, TFS work items, other LOB applications, but also 3^rd party sources like Bing maps or data sets bought from the Azure market place containing daily coal prices, social media information etc.), or even files living on a network share (that company hour-tracking Excel file that’s always locked, an XML of CSV file containing data that gets exported from a 3^rd party application by an nightly process etc.).

Entities represent real-life objects (or parts thereof).  They are not mere data structures but intelligent binary creations that encapsulate business logic.  Some business logic will be unique to the Entity or specific property, other logic might be quite common in the particular business or even in general.  LightSwitch will refer to this common logic as ‘Business Types’.  Business types are a superset of data storage types (string, int, binary, …) that have a unique set of business logic and validation rules, examples include ‘Money’, ‘Email address’, ‘Phone number’, ‘Barcode’, … 

Besides business logic limitations, all entities will suffer from system limitations: limitations imposed by the backing data source like the maximum length of a particular field, the number of decimal fractions that can be stored…  

Entities aren’t isolated cells, but instead interact with each other according to a set of balanced and protected ‘Relationships’. 

It’s an accepted best practice to enforce those relationships where possible, but this isn’t always possible in the data source.  Besides, two entities might have a relationship according to the business regardless of being persisted in different, isolated data stores. 

Almost all LOB applications will designed for multi-user purpose.  This means that the software cannot be a monolith of bytes on a single pc, but instead should be vertically sliced per reusability and horizontally sliced per deployment location.  These horizontally sliced blocks are often referred to as tiers.  Multi-user LOB applications commonly consist of a ‘Data tier, Logic tier and Visualization tier’.  In the vocabulary of a LightSwitch developer, these three types of tiers in such a multi-tier architecture are known as ‘Data sources, Middle Tier and Clients’.   Entities will really exist in all different tiers.  Ideally, their business logic and their relationships are enforced on each tier as well, increasing the way a layer is autonomous, and thus increasing the overall reusability of the layer. 

Each tier is structured internally according to specific architectural and/or library design patterns.  A client tier, for example, can be structured according to the MVVM (Model-View-ViewModel) pattern where a visualization layer (View) binds to a specialized layer (ViewModel) that reshapes and juggles the Models around to expose them as data structures and reusable commands that are more tailored to visual consumption. 

End users of a LOB application are often non-techy savvy people that think about their work in specific business terms.  Good LOB application developers will understand this and not limit the end user to only the CRUD commands (Create, Read, Update and Delete) or displaying all data in grids.  (I have gridophobia, by the way.)  Good LOB application developers will understand the specific use of the application and use typography, colors, custom layouts and specialized controls tailored to the particular business process and particular end. 

This also includes an adaptive design (the layout and/or controls are changed depending on the type or screen factor of the device), utilizing device specific capabilities or supporting speech or touch gestures (if applicable) and in some cases: support for multiple languages.

Finally, when new features are completed by the developer, the code gets pushed to source control, compiled (if needed) and then deployed.  The release cycle is best kept as short as possible so that feedback can be incorporated early and often, hence a good deployment model should be highly automated in order not to slow down the release cycle.  

The end users then install the application (or simply browse to the web application) and start using what is accessible to them.  There’s a magnitude of known authentication and sometimes complex authorization models to make sure data and business processes are safeguarded against unauthorized users.

The LightSwitch IDE

Your honor, members of the jury.

To prove my opening statement that “LightSwitch is a combination of frameworks and tooling to aid professional developers on their quest to build highly specialized LOB applications (stand-alone or as part of a bigger system) in rapid release cycles without having to compromise on interoperability or flexibility (by enforcing industry proven standards and patterns and promoting scalable architectural designs)”, I have highlighted several key aspects of LOB application development in Exhibit A (‘What are LOB applications?’) and will now demonstrate how the LightSwitch IDE addresses and implements them.

The LightSwitch IDE mainly utilizes specialized designers to design Entities, Queries and Screens.  These designers abstract the technological aspects and removes a lot of the tedium involved, to allow you as a professional developer to focus only on the business aspects initially.

The Entity designer (‘Entities’) is automatically opened if you start the application like you did in the previous chapter: by right clicking on the Data Sources folder of the server project and selecting Add Table.

Data Sources context menu

 This command automatically caused LightSwitch to add a new Data Source called ApplicationData.

The intrinsic data source

This data source will hold all entities that are specific to your application (‘Intrinsic data source’). 

LightSwitch also has some options to connect to existing data sources (‘Data source’).  Selecting the option Add Data Source from the same context menu will open up a wizard to help you connect to a variety of options.

Connecting to an existing data source

‘Database’ allows you to connect to any existing database. 

‘SharePoint’ creates a connection to a SharePoint site so you can use any of the SharePoint lists in your application. 

‘OData Service’ allows you to connect to any web service that is exposed via the Open Data Protocol (http://OData.org ).  In its turn, every LightSwitch application uses JSON Light (an OData implementation) to expose the middle tier to the LightSwitch or 3^rd party clients.  This means that you can use the ‘OData Service’ connection to connect a new LightSwitch application to the entities in an already deployed LightSwitch application, boosting reusability.  

A ‘WCF RIA Service’ can be any class that inherits from the DomainService base class.  This allows developers to quickly create an adapter in code between the LightSwitch application and anything they can connect to from code: CSV or XML files, SOAP services, Office documents or whatever proprietary format they want.

The entity designer promotes OO principles by making sure that you implement the logic where it belongs: encapsulated by the entity.  Each field has a ‘Business type’ (‘unique Business Types’).  LightSwitch has almost 20 built-in business types (ranging from simple data types like Boolean or string to more complex types like Email or Money). 

Customer entity in the Entity Designer

Apart from proprietary built-in validation (for example: email validation), each business type exposes some additional specialized properties in Properties Window. Money, for example, will both have properties that are typical to the backing data field (Decimal Places to name one) and properties that are inherent to the business type (Currency Symbol for example).

If you connect to an existing data source, the former type of properties will be disabled for change (limitations imposed by the backing data source), like the Maximum Length or Size of the field.

Screen designer showing extended properties and code entry points

If you need more control to encapsulate the business logic, you can have a method (or function) stub generated with a click on the Write Code button at the top of the Entity designer.  Some methods will run server-side or client-side only, others run both on the server and on the client (for example: the ‘created’ method that executes when a new instance of a particular entity is created, useful for initialization purposes). 

To avoid ambiguity, change the ‘Perspective’ at the bottom of the Entity designer to indicate where you want your custom code to run.

Sometimes all you need is a change of perspective

Depending on your perspective, a JavaScript or a C#/VB.Net class will automatically be added.

Custom code stored in JavaScript or .Net code

Although you cannot see this in the Entity Designer, each entity has a couple of automatically maintained columns for auditing (named CreatedBy, Created, ModifiedBy and Modified) and concurrency checking (named RowVersion).

Another featured button in the command bar of the Entity Designer is the RelationShip button.  This allows you to model the ‘Relationships’ between different entities.

The relationship dialog

This dialog allows you to design relationships as they exist in the perspective of the end user.  This may or may not be the same relationships as present in the data source, this may include self-referencing relationships and this may include relationships between entities over different data sources.

Custom business rules expressed in code, business rules inherited by the business type of the properties and relationships, will be validated/enforced on every single layer (‘Data sources, Middle Tier and Clients’) where possible.  Each layer is autonomous in the way that it will protect the business rules within that layer as much as possible instead of trusting the caller.  Being autonomous increases security (a crafty employee might try to circumvent client-side validation by calling the services directly) and promotes reusability.  As a non-optional feature, a LightSwitch project will always expose the middle tier as a web service using the OData protocol. 

The ability to connect to different legacy sources, redesign and combine the entities and expose them via an industry-proven, open standard like OData, is a really powerful way extend the lifespan of legacy data and software.  This scenario is explicitly embraced by allowing you to deploy only the middle (and data) tier from the LightSwitch deployment wizard (which you’ll cover in more detail later).

Let’s zoom in on the third tier: Clients.  You can connect to the OData middle tier with a simple web browser, Excel (great for self-service BI PowerPivotting) or just code together a custom client with the help of one of many available libraries (they exist for all major development languages but in the end it’s just HTTP requests so you could even roll your own if you are stuck in a legacy development environment).

Besides developing a client by hand, a LightSwitch application allows you to add ‘LightSwitch clients’ as well.  Yes, plural, as in: zero, one or multiple clients. 

Adding a client is done by right clicking on the LightSwitch client itself in Solution Explorer and selecting Add Client from the context menu.

Adding a client to the LightSwitch project

The Add Client wizard will appear which (at the time of writing) allows each LightSwitch project to contain one mobile client and one desktop client.

Client type selection dialog

The Add Client wizard appears to have plenty of room to grow, suggesting that the team is leaving the option open to support additional client types at a later stage.

The Mobile Client (which was already added by selecting the ‘LightSwitch HTML Application’ project template when creating the project) is an HTML5/JavaScript SPA (so that it can run on all modern mobile browsers).  It has a mobile oriented nature at the moment, however as the team tackles their sprints it is evolving into a mobile-first experience that will allow you to use one HTML client for mobile and desktop use.

The Desktop Client is an out-of-browser Silverlight application (with full support for COM interop, like the built-in options to export data to Excel or starting a client process from within the application).  This Silverlight client can also be ran inside a sandbox in the browser (losing the COM interop but gaining the ability to be deployed as a SharePoint app, just like the Mobile Client).

All supported clients enforce the same design pattern: MVVM.  The added bonus of this common trait is that the LightSwitch Screen Designer looks almost exactly the same whether you’re creating screens for the Mobile or for the Desktop Client.  This lowers the learning curve for new types of clients substantially.

The Models in this MVVM design are already generated based on the information in the Entity Designer and are visible in Solution Explorer.  On the left hand side of the Screen Designer you can design the View Model; the right hand side (and thus center of the screenshot below) displays the View.

MVVM, or in order of the LightSwitch IDE: VM V M

The View Model layer basically serves to prepare the Models for easy consumption in the View.  More specifically, it will add state intended only for visualization purposes in a specific part of the application, like the ‘selected item’. 

The Add Data Item button in the command bar of the Entity Designer allows you to add additional items to the View Model to help you store whatever visualization state you might need.  These items can be a Local Property (for example: a date which will then be used as a parameter to filter a collection), a Query (which also adds the notion of a ‘Selected Item’) or a Method (LightSwitch lingo for a reusable command).

Adding Data Items to the ViewModel

Commands have two code entry points, one that is called when the command is executed and one that returns a value indicating if the command can currently be executed. 

The command pattern

This allows you to finetune availability to restrict execution of a command to a particular group of end users or only allow the command to be executed if the ViewModel is in a particular state.  The View will let the user know if a command cannot be executed by disabling the corresponding buttons or even making them invisible.

Speaking of display: the right hand side of the Screen Designer displays the View.  To be 100% exact, it doesn’t actually display the view (which would be HTML or Silverlight XAML) but rather a technology agnostic abstraction that describes what the View will look like.

The LightSwitch libraries will use this abstraction to create the View layer at runtime by dynamically adding new HTML elements to the ‘root’ HTML element in the single HTML page.  The View in the desktop clients is not generated at runtime in the same way, but that technical implementation detail is well beyond the scope of this eBook.

The ‘View’, or a technology agnostic metadata driven abstraction thereof.

Each node in this visual tree is called a ContentItem.  A ContentItem is databound to a particular part of the ViewModel and provides additional information about the way it will be visualized to the user.  Each ContentItem has a number of ways it can be visualized (depending on the Business type of what it’s bound to), available by clicking the dropdown arrow next to the icon on the node.

Available controls and properties for a ContentItem in the View

Additionally, each ContentItem node exposes additional properties in the Properties Window to further control the layout, size, font, …  This will of course further be enhanced by the active CSS (Mobile application) or selected Theme (Silverlight Desktop application) in combination with custom code you can add to override the rendering.  LightSwitch also offers you some specialized layout controls (rows layout, tabs layout, columns layout, group box, etc) and the ability to create a Custom Control from scratch, right on the spot.  All the tooling you’ll ever need to enhance your application with typography, colors, custom layouts and specialized controls is available, and you’ll cover as much as possible in later chapters.  

Besides looks, some properties allow you to set up actions or write custom code to respond to particular touch gestures with a single click.

Touch gesture actions like Item Tap

Notice how there’s no option, properties or buttons in the Screen Designer to help create an adaptive design as this is provided out-of-the box, 100% effort-free.

After designing the application, it’s time to select an authentication model.  Select the LightSwitch application in Solution Explorer and open the Properties.  The Access Control tab will allow you to select an authentication model that fits the existing IT infrastructure in the company with the click of a radio button.

The Access Control tab.

From the same tab a developer can add custom Permissions to the application.  These permissions can then be checked in custom code to allow or restrict the end user to execute particular commands or open particular screens, but also for vertical or even horizontal data security like editing particular fields on an entity or even hide particular rows from the database.  An administrator (anyone with the SecurityAdministration Permission) can then group the end users into User Groups (or reuse the Active Directory security groups in the case of Windows Authentication), and assign a subset of these Permissions to each group.  This allows for authorization to be as fine-grained as the business requires it to be.

From the General Properties tab, you can pick the application’s language from 41 supported languages. 

The General Properties of a LightSwitch application.

A single application can also support multiple languages simultaneously, which I didn’t cover in this book but you can read all about it on http://msdn.microsoft.com/en-us/library/vstudio/xx130603.aspx.

The number of available tabs will differ depending on your type of LightSwitch application.  We set out on a mission to create a mobile business app, but if you wanted to use LightSwitch to create Cloud Business Apps as well just start your journey with the Cloud Business App project template.

Cloud Business App project template.

This project template will create a LightSwitch application that is pre-configured to be deployed to a SharePoint 2013 server, either on premises or in the cloud, like an Office 365 site.  SharePoint development will also not be covered in this eBook but here’s the getting-started-link (http://msdn.microsoft.com/en-us/library/vstudio/jj969620.aspx) for your next coffee break. 

Enough with the SharePoint detour, let’s shift focus back on the tabs that are available your current project: the Extensions tab.  LightSwitch has an SDK that you can download from (http://visualstudiogallery.msdn.microsoft.com/2381b03b-5c71-4847-a58e-5cfa48d418dc).  With this SDK, you or anyone else can create additional, reusable adapters to different Data Sources, new Business Types of Controls, Screen templates and even company specific shells and themes.  (The last four are limited in use for the desktop client only, at the time of writing).  These extensions would then be packaged in a VSIX.  Once you have installed such a VSIX, you can activate it per LightSwitch project in this tab.

Some major component vendors, Syncfusion included, have already wrapped all of their Silverlight controls in reusable LightSwitch controls.  If you are interested, make sure to check out Essential Studio for LightSwitch at http://www.syncfusion.com/products/whatsnew/lightswitch  and see how easy it is to combine the Rapid Application Development power of LightSwitch with the Innovation of Syncfusion.

Speaking of awesome

Remember that these VSIX files have to be installed on your build server as well or else it will fail to compile your LightSwitch project based on the source code it just pulled from source control.  LightSwitch uses editors in the IDE, but behind the scenes a LightSwitch solution contains normal projects that can be checked in or pushed to any source control, just like any other project.  If you are interested, additional guidelines and best practices on working on a LightSwitch project with multiple developers at the same time, can be found at http://blogs.msdn.com/b/lightswitch/archive/2013/07/09/team-development-series-introduction-peter-hauge.aspx

Before moving on, here’s some additional information about the elements in the General tab that I haven’t mentioned yet: Version Number, Publish and SQL Database Project.

LightSwitch uses semantic versioning, it’s the responsibility of the developer to keep major and minor version number up to date, patch number will be automatically increased each time you hit that publish button…

Publishing takes one click on the button, how’s that for a highly automated deployment model?  Well ok, the button will start a wizards and you’ll need to pressure your fingers a couple of more time to complete the entire publishing process.  This process will be covered in more detail later, for now my throat is soar from all this talking so I’ll rest my case on LightSwitch being awesome tooling for LOB application development, roll up my sleeves and dive in the last of the properties on the General Properties tab that I haven’t mentioned yet: the SQL Database Project.

.