Introducing LightSwitch
When I first began working in LightSwitch, I was mystified at how everything worked. Although you can build applications quickly, easily, and with minimal effort, this simplicity is possible only because LightSwitch abstracts away much of the internal workings and plumbing code. At first, this isn’t a problem, because there’s no need to understand what happens beneath the surface. But as your applications become more complex and sophisticated, application development makes more sense if you understand how both the underlying architecture and the build process work. Therefore, this chapter will provide an overview of the parts that make up an application, which it will do by describing the following key topics:
- The three-tier architecture that LightSwitch uses
- How LightSwitch applications are based on XML models
- How LightSwitch applications apply the MVVM pattern
By the end of this chapter, you’ll understand how LightSwitch applications are architected, and also recognize what happens when you build and compile an application.
Let’s begin by taking a look at the history of LightSwitch. Back in 2010, Microsoft released the very first version of this tool. Microsoft designed LightSwitch as a rapid application-development tool for building Silverlight-based, data-driven line-of-business applications. Businesses could use LightSwitch to build applications for storing, viewing, and retrieving data. Example use cases might include applications for managing sales figures, assets, or customers. In fact, any application that requires a “forms-over-data” interface is an ideal candidate for LightSwitch. The fact that LightSwitch is Silverlight-based meant that Microsoft could market the product as a tool for building both desktop and web applications.
As a first release, the product worked very well. It filled a niche in the market and liberated many developers. Of course, there were various things that didn’t work so well, but you’d expect this from a first release. In 2012, Microsoft updated LightSwitch as part of the Visual Studio 2012 release. This release included bug fixes, new data types, and controls. It also added localization support and replaced a dependency on SQL Server Express at design time with LocalDB. Prior to this, there were often occasions at debug time when the running application would fail to load data and would show a red X instead. The introduction of LocalDB did a lot to improve design-time reliability.
As time progressed, the Silverlight nature of LightSwitch became more of an issue. The browser applications that LightSwitch generates require the user to install the Silverlight plugin, and this plugin isn’t available on all platforms or devices. Not only were Silverlight and third-party plugins falling out of favor, but also the use of Silverlight presented a practical problem in that LightSwitch applications wouldn’t work well on mobile devices, the Apple iPad being a prime example. To address these issues, Microsoft added the HTML client during a second update to Visual Studio 2012. This major new feature allowed developers to create native HTML5 applications that worked on all major web browsers. To support this change, Microsoft changed the method that the LightSwitch client used to communicate with the server. The underlying implementation changed from RIA Services to OData. Despite the fact that this was a major structural change, it would have been invisible to most developers and end users.
Further changes to LightSwitch came in Visual Studio 2013. Microsoft added the ability to host your application as a SharePoint app. The benefit of this is that it enables LightSwitch applications to be integrated into SharePoint. This feature also better aligns LightSwitch with Microsoft’s cloud strategy. It means you can choose to host your application through Microsoft’s SharePoint 365 subscription service, and to leverage the Office 365 services as well. In Visual Studio, Microsoft added a Cloud Business Apps template. This makes it possible to use LightSwitch technology to build applications that are targeted for Azure.
As a result of all the advancements since the first release, LightSwitch has reached maturity. Thus, the 2015 release contains fewer new features. Despite this, if you need a way to quickly build line-of-business applications, my view is that LightSwitch remains one of the best tools on the market.
Understanding LightSwitch’s Architecture
A problem some organizations face is that often application development is carried out by individuals whose main job is not in IT. The stereotypical applications that such developers produce include enormous Excel spreadsheets with convoluted VBA (Visual Basic for Applications language), or poorly thought out Access databases. Although these developers are very smart in their own industries and business processes, they aren’t formally trained and don’t know how to properly structure an application. When the person leaves, the business can end up inheriting a mess of an application that’s very difficult to maintain.
With LightSwitch, this problem is less likely to occur, because the application imposes an architecture that separates user interface, business logic, and data. When you create a new solution, LightSwitch creates separate projects that are built to execute on a specific tier in this architecture. LightSwitch makes it difficult for you to write code in the wrong place (for example, business-logic code in the user-interface layer), and this in turn leads to applications that are more maintainable and scalable.
Figure 1-1 illustrates the parts that make up a LightSwitch application. It highlights the way that applications are separated into data, logic, and presentation tiers. It also illustrates how each tier communicates with the others.
Figure 1-1. LightSwitch’s architecture
The data tier describes the place that physically stores your data. With LightSwitch, you can read and write data that’s stored in SQL Server, SQL Azure, SharePoint, and many other data sources. These data sources make up the data tier. In fact, your data storage options are almost limitless. This is because you can connect to almost any data source by creating your own custom RIA service.
A very special database that exists in all LightSwitch applications is the Intrinsic (or Application Data) database. LightSwitch inserts any table you add through the Visual Studio designer into this database. Another purpose of the Intrinsic database is to store user details. LightSwitch uses the ASP.NET SQL membership provider to manage users and roles. The database tables that are used by the membership provider are stored in the Intrinsic database.
During design time, LightSwitch hosts the Intrinsic data using LocalDB (the successor to Microsoft SQL Server Express). But when you deploy your application, you can host the Intrinsic database using any version of SQL Server 2005 or above.
The LightSwitch client application doesn’t communicate directly with the underlying database or data store. Instead, it performs data access by calling services in the logic tier. There are two places where you can host your logic tier. In the case of a Silverlight desktop application, you can configure the logic tier to run on the end user’s machine. But in the case of a web application, you need to host the logic tier on a web server. Technically, LightSwitch builds an ASP.NET application that you can deploy to an IIS Server, or to Azure.
LightSwitch creates a data service for each data source in your application. Data services are responsible for reading and writing data to the data source, and they also perform any business logic that’s applicable (such as data validation). LightSwitch exposes the data service as an OData end point at the logic-tier boundary.
When the LightSwitch UI carries out some data access, it does so by communicating with an OData end point that the data service exposes at the logic-tier boundary.
Data services expose entity sets for each table in the corresponding data source. Entity sets are containers for items of the same record type, and all data access is carried out through an entity set.
Entity sets expose operations that return data to the client. By default, these operations include queries that return all records in a table, or single records filtered by a primary-key value. Any queries that you create are also exposed as operations via the entity set.
Figure 1-2 illustrates a typical data operation. When the LightSwitch UI requires data, it calls a query operation on the entity set. In this example, the query operation relates to a user-defined parameterized search query to find customers by surname. This query allows the client to pass in an argument that specifies the search criteria.
Figure 1-2. Calling a query that returns customers filtered by surname
When the data service executes the query, it passes through the Query pipeline. This opens up various phases where you can add your own custom code. During the pre-processing phase, for example, you can tailor the results of a query by adding extra filter conditions using LINQ (language-integrated query) code.
Entity sets provide an operation called SaveChanges. As the name suggests, this method starts the process that saves any updated data. Let’s see how this save process works.
At the very beginning (before SaveChanges is called), the client calls a query operation on an entity set that returns an initial set of data. The client caches the data that the query returns. When a user modifies data, the client generates an object called a change set. This object contains the deltas, and the application uses this to maintain a record of any records that the user adds, updates, or deletes.
When the user clicks on the Save button, the LightSwitch client calls the SaveChanges operation and passes in the change set. Before the changes are committed to the database (or the underlying data store, such as SharePoint), the processing enters the Save pipeline.
Just like the Query pipeline, the Save pipeline provides places where you can intercept the save operation by writing custom code. For example, you can prevent certain users from updating data by including code in the Save pipeline.
We’ve already seen how LightSwitch applies best practices without you having to do much extra work, and the Save pipeline is yet another example of this. If LightSwitch detects conflicting changes that have been made by other users, it won’t allow the save operation to succeed. Instead, it shows what the current and proposed values are, and allows the user to choose what to do.
LightSwitch also maintains the consistency of your data by applying all updates inside a transaction. For example, any proposed change to a parent record won’t be applied if an update to a child record fails.
Without LightSwitch, you could spend ages writing this type of boring, repetitive, boilerplate code. This is yet another example of the timesaving that you can achieve with LightSwitch.
The presentation tier defines the part of LightSwitch that runs on the user’s computer or device. The tier actually performs a lot of work. It shows data to the user, allows data entry to happen, and controls all other tasks that relate to human interaction.
Importantly, it also performs business logic such as data validation, keeps track of data changes, and interacts with the data services in the logic tier. You can build your user interface (or client) by using either Silverlight or HTML. In fact, the choice isn’t mutually exclusive. You can include both Silverlight and HTML clients in a single LightSwitch application.
Microsoft introduced the HTML client in LightSwitch 2012. This client is highly recommended if you want your application to work on mobile or touchscreen devices.
The advantage of using the HTML client is that your application can work on a wider range of devices. In comparison, a Silverlight application running in a browser requires the user to install the Silverlight runtime. This isn’t always possible, particularly on mobile devices or on locked-down corporate environments.
You can customize HTML-client applications by using JavaScript and CSS (cascading style sheets). If you have experience writing web applications, you can very easily use your existing skills.
For more traditional developers, coding in .NET code is usually easier than doing so in JavaScript. For these developers, the Silverlight option can offer better productivity.
The benefit of a Silverlight front end is that it provides a rich experience for both developers and end users. For example, you can carry out COM automation or automate Microsoft Word/Excel using Silverlight. This isn’t possible with an HTML client.
It’s also easier to write client-side code when you’re using Silverlight. You can use strongly typed C#/VB code and carry out more tasks in code. For example, you can perform security operations or use LINQ syntax to query data on the client.
You can set up your Silverlight client to run either out of browser as a desktop application or inside a browser as a web application. You can switch your application from one mode to the other by simply clicking a radio button in the properties of your LightSwitch project.
LightSwitch web applications are hosted through the Silverlight runtime that the user installs in their browser. Your application executes inside a sandbox, and access to features such as Export to Excel is prohibited. Access to certain parts of the file system is also restricted.
In the case of a desktop application, the hosting service is provided by the Silverlight out-of-browser host service (sllauncher.exe). In this scenario, your application is automatically configured to require elevated permissions, and therefore has access to features such as Export to Excel and COM-based automation.
Shells are a feature of the Silverlight client. They control the location of all major UI elements and perform application level tasks. Examples of the tasks that a shell carries out includes handling the logging in process, building screen navigation menus, and composing the screens that application shows to the user.
You can set the shell for each application through the properties pane of your project. The two default shells that ship with LightSwitch are called Standard and Cosmopolitan. (See Figure 1-3.)
Figure 1-3. Standard and Cosmopolitan shells
LightSwitch provides many extensibility choices, and if you don’t like these built-in shells, you can choose to write your own.
Applying Themes to Your Application
Themes are another feature of the Silverlight client. They contain a set of styles and help control the fonts and colors that your application uses. Unlike when changing the shell, themes apply presentational changes that are much more subtle.
As with shells, you can use the properties pane in your project to set the theme for an application. Themes are often designed to work with a specified shell, but it’s entirely possible for you to mix and match the shells and themes.
The way to manage the look and feel of an application is through shells and themes. New developers often struggle to set control attributes (such as fonts and colors) because many of these attributes are designed to be controlled by a theme, rather than set for each individual control. Once again, LightSwitch applies good practice by encouraging you to apply consistent style settings throughout your application.
Themes are also one of several LightSwitch extension points, and I’ll show you how to create your own later in the book.
Understanding LightSwitch Screens
A screen represents a piece of user interface that users can utilize to view or enter data (just like a form in an Access application or a web form in an ASP.NET application).
Developers create screens with prebuilt functions by using templates. For example, there are templates for creating search, data edit, and data entry screens. You can also create your own screen templates—this is another extensibility point that LightSwitch offers.
Desktop applications feature a tabbed interface. Users can open multiple screens, and each screen opens in a separate tab. Each screen contains an object called a data workspace that is responsible for fetching and managing data. The data workspace manages the state of the data in the change set that is submitted to the data service on the logic tier when the user initiates a save. Because each screen contains its own data workspace, data changes that a user makes in one screen are not visible in other screens. You can’t share data changes between screens, because each screen maintains an independent view of the data.
Unlike desktop client applications, HTML client applications feature a single document interface and can only show one screen at a time. All screens in an HTML client application share the same data workspace. If a user makes data changes on multiple screens, the application’s Save button will commit all of the data changes that have made during the session.
When you write screen code, you need some way to reference objects such as data, controls, or screen parameters. These objects are exposed via an object called the screen object, which you’ll learn how to use in later chapters.
Introducing the Model-Centric Architecture
LightSwitch’s model-centric architecture is a brilliant piece of software engineering. The model-centric architecture defines your LightSwitch application (data items, screens, queries) within XML files that are named with an LSML extension. When you run your LightSwitch application, the LightSwitch runtime processes the XML data and transforms it into a working application.
As a very loose analogy, think of the LightSwitch runtime as a copy of Microsoft Word. Using this analogy, your LightSwitch application would be a Microsoft Word document. In the same way that Word opens Word documents and makes them readable and editable, the LightSwitch runtime opens LightSwitch applications and makes them functional.
The advantage of this architecture is that LightSwitch isn’t strongly tied to any specific technology. If Microsoft wants LightSwitch to run on a different platform or device, it can be done by simply writing a new runtime. Following on from version 1 of LightSwitch, this is exactly what happened with the HTML client. As another example, Microsoft changed the communication protocol between the client and server from RIA Services to OData with the release of LightSwitch 2012.
Figure 1-4 shows the parts that make up a LightSwitch application, from design time through to runtime. For desktop applications, a solution consists of three groups of .NET code: client, common, and server code. Server code runs on the server, client code runs on the client, and common code runs on both the client and the server. An example of common code is data validation. In most cases, the client validates data before sending it to the server. When the data reaches the server, the server revalidates the data using the same common code.
Figure 1-4. LightSwitch build process
Note that with the HTML client, the notion of shared common code doesn’t exist, because the server and client are based on different technologies. The server components are based on .NET, while the language that is used on the client is JavaScript.
To further explain the build process, let’s start at the bottom of the diagram in Figure 1-4. As part of the model-centric architecture, LightSwitch applications are constructed from building blocks. Think of these as XML representations of the objects that you find in the LightSwitch designer. Let’s say that you add a data source to your application. When you do this, LightSwitch expresses your data source as an XML element inside an LSML file in your server project. When you finish in Visual Studio, your application will be defined entirely in XML, and this is known as the LSML Model.
During the build process, LightSwitch auto-generates classes that support your application. This auto-generated code includes the data workspace classes and the screen object classes. When you build your application, LightSwitch compiles the .NET code in your application. This code includes the auto-generated code, in addition to any custom code that you write.
The interesting thing about the LightSwitch client is that the solution doesn’t include any files that contain UI definitions in XAML (Extensible Application Markup Language) or HTML. Instead, the LightSwitch runtime dynamically generates the screens and UI at runtime. In the case of the Silverlight client, the dynamic generation of screens, controls, and the shell takes place using MEF (the Managed Extensibility Framework) and data templates.
This dynamic generation prohibits developers from directly modifying the XAML or HTML that the application produces. More experienced developers who prefer to hand-craft the raw UI can find this behavior limiting. However, LightSwitch does provide some flexibility for building custom UI elements in XAML or HTML through custom controls and methods in the HTML client.
Note You can create LightSwitch projects in C# or VB.NET. However, you can’t change a project from one language to the other after it has been created.
Understanding MVVM (Model-View-ViewModel)
LightSwitch applications follow a design pattern called M-V-VM (also known simply as MVVM). This pattern was developed by John Gossman (a technical architect at Microsoft) and is commonly used by Silverlight developers.
MVVM keeps the presentation, logic, and data elements of your application logically distinct. This pattern helps you develop applications that are cleaner, more maintainable, and more testable.
The Model part of MVVM refers to the conceptual representation of the data. The entities and queries that you define in your application make up the model.
At runtime, LightSwitch constructs a screen layout by interpreting the LSML model. The screen layout consists of a tree of content items, which could represent data items, lists, commands, or items that control the layout of your screen. A content item at runtime represents the View Model element of MVVM. The view model controls the client-side business logic (e.g., validation) and also manages data access.
Next, the LightSwitch runtime builds a visual tree that contains the controls that it shows on screen. The Silverlight or HTML controls make up the View part of MVVM. Views are designed only to display data—nothing more. Because views are designed only to display data, you can easily change the control that’s bound to a data item (Figure 1-5). This is one of the biggest benefits that the MVVM pattern offers you.
Figure 1-5. Changing the views that are bound to a data item
Walkthrough: Creating a LightSwitch Project
So far, we’ve covered a lot of theory. To round off this chapter, I’ll move on to something practical and show you how to create a new project. This section will help you familiarize yourself with the Visual Studio designer, and also help you understand the layout of a LightSwitch solution.
Start by opening Visual Studio and choosing the File 
New Project option. In the list of templates, you’ll find the option to create either a Desktop or HTML Application (Figure 1-6).
Figure 1-6. Creating a new project
Choose “LightSwitch HTML Application,” enter a name for your project, and click the OK button. Once you do this, you’ll see the view that’s presented in Figure 1-7. Note that if you don’t see the LightSwitch templates, re-run Visual Studio setup and check that you’ve selected the LightSwitch option.
Figure 1-7. What you see when you first create a project
Notice that the view in Solution Explorer contains three nodes: a node that represents your application, an HTML client project, and a server project. As the names suggest, the server project contains the code and objects that run on the server, whereas the HTML client project includes the HTML/CSS/JavaScript code that runs on the browser. If you choose to create a desktop application, you’ll see a desktop client project, rather than a HTML client project.
The initial start screen helps you get started by providing quick links to either create a table or to attach an external data source to your application. In the next chapter, I’ll show you how to set up your data.
You can access a variety of menu functions through the right-click and context menu items for these three nodes. Here’s an overview of what you can do through these items in Solution Explorer:
- Application: This enables you to configure general, extension, and access control properties. You can use the right-click menu option here to add additional clients.
- Server: The server project enables you to manage tables, data structures, and queries.
- Client: The client project enables you to create screens, edit the menu items in your application, and write code that runs on the client.
Setting Application Properties
Through the properties of the application node, you can configure general properties that relate to your application as a whole, as shown in Figure 1-8.
Figure 1-8. Application properties
An important menu option that you can access through the right-click context menu of the application node is the option to add additional clients. Although we initially created a HTML application, LightSwitch solutions can include both HTML and desktop clients. An application with both clients might contain a fully rich desktop client that’s designed for office workers, with a scaled-back HTML client that contains a read-only, or subset of features, and is designed for mobile workers. Of course, the advantage of a solution with two clients is that both client applications can share the same server-side objects, such as code, queries, and validation.
To add an additional client, right click the application node and choose the “Add Client” option to open the dialog that’s shown in Figure 1-9. Click the OK button to add the additional client to your project.
Figure 1-9. Adding additional clients
During development, you can debug and run your application by clicking the F5 button, or by using the green Play button on the Visual Studio toolbar. In a solution that contains both HTML and desktop clients, you can select the client you wish to debug by selecting the right-click “Set as startup” menu option.
LightSwitch gives you the ability to host your HTML client applications in SharePoint. An important point to bear in mind is that once you add a desktop client to your solution, you can’t later deploy your project to SharePoint. So, if you want to deploy an HTML application to SharePoint, make sure not to add a desktop client to your solution!
Now that you’ve seen how to create a LightSwitch project, Chapter 2 will show you how to create tables and how to attach your application to existing data. Once you set up your data, I’ll show you how to build HTML and desktop client applications in Chapters 3 and 4.
Summary
LightSwitch is a perfect tool for quickly building data-centric desktop or browser applications. Examples of applications that are ideal for LightSwitch include internal auditing, asset control, or customer database systems.
The applications you build with LightSwitch are robust, because LightSwitch follows well-known patterns and best practices, such as three-tier application layering and MVVM. Applications consist of data, business logic, and client layers. For the client layer, you can build LightSwitch “front ends” using either Silverlight or HTML. A Silverlight application provides a richer experience, and can run as a desktop application. Desktop applications can interact with other desktop applications such as Outlook and Word, unlike a browser application. HTML applications are generally less powerful than their Silverlight counterparts, but benefit from being compatible with a far wider range of platforms and devices.
With LightSwitch, you can read and write data belonging to SQL Server, SQL Azure, SharePoint, and many other data sources. All LightSwitch applications rely on a special database called the Intrinsic database. This database stores the tables that you create within LightSwitch, as well as the login details for your users.
The LightSwitch client applications don’t talk directly with your database or data source. Instead, they access data by communicating with the logic layer. At the logic-tier boundary, LightSwitch creates a data service for each data source in your application. The LightSwitch client uses the OData protocol to communicate with the data service and to carry out data retrieval and update operations.
Data access in LightSwitch revolves around the concept of a data workspace. Think of this as an object that provides access to the data sources, queries, and tables in your application. Each data workspace maintains a change set. A change set keeps track of data changes, and LightSwitch uses this to stop users from accidentally overwriting changes that other users have made. Desktop applications feature a tabbed interface, with each screen appearing in a separate tab. Each screen maintains its own data workspace. This means that each screen maintains an independent view of the data. Therefore, any data changes that a user makes on one screen won’t be visible on other screens.
HTML applications, on the other hand, feature a single document interface. All screens in a HTML client application share a single data workspace. If a user makes data changes on multiple screens, the application’s Save button will commit all of the data changes that have been made during the session. Having said this, the typical layout of an HTML client application usually prevents users from committing changes that they don’t currently see on the screen.
When the server fetches or saves data for the client, code execution passes through the Query or Save pipelines. These pipelines expose points where you can write custom .NET code. For instance, you could write auditing code, or code that customizes the output of a query.
For Silverlight applications, shell and theme settings enable you to reclothe or “skin” your application. Changing the shell allows you to radically change the appearance of your application, whereas changing the theme produces more subtle changes, such as with font colors and sizes
LightSwitch applications are defined using XML building blocks, and the XML content is persisted in files with an LSML extension. LightSwitch auto-generates the client UI at runtime by interpreting the XML model. Therefore, your Visual Studio project won’t contain screen definitions in XAML or HTML that you can hand edit. LightSwitch uses the MVVM pattern. A big advantage of this pattern is that it keeps your project logically distinct and allows you to easily change the controls that are bound to data items.