Microsoft has long made development tools available to people who are not professional, full-time developers. They made a brilliant move many years ago when they added Visual Basic for Applications (VBA) and other scripting languages and tools to some of their consumer and business-oriented products, most notably various products in Office. As a result, there are probably millions of applications written using Microsoft Excel and Access that run businesses large and small, built by people with deep domain knowledge but little or no development training.
But there has long been a gap between these Excel and Access applications and more widely used commercial and enterprise-class applications. Often when a power user's application needs to scale up for wider use, the company discovers the limitations of Excel and Access and has to call in professional developers to rewrite it from scratch using "real" tools like Visual Basic (VB), C#, and Visual Studio. There just haven't been any good, scalable migration paths for these apps, despite lots of effort by both Microsoft and outside vendors.
Recognizing this gap, in late July 2011 Microsoft released version 1.0 of Visual Studio LightSwitch 2011, a constrained development environment for creating rich applications whose main purpose is to let users interact with data. The product is constrained in that it uses specific technologies and does things in a specific way, albeit with plenty of ways to customize the application through extensions and custom code.
A LightSwitch application is built on several key technologies, all of which are the current state of the art in the Microsoft stack, including:
- Silverlight 4.0 for the user interface
- Windows Communication Foundation (WCF) RIA Services for communication between application layers and as a powerful point of extensibility
- Office automation to let users export customized views of data and interact with Office applications
- Entity Framework for object-relational mapping (ORM) services to the underlying data stores
- OData for querying and updating data using HTTP, ATOM, and JSON
- Various data stores, including SQL Server, SQL Server Express, Windows Azure, and SharePoint
On the face of it, this list of technologies would be intimidating to power users, and even to many professional developers! But LightSwitch takes care of all the details for you, so that you don't need to know any of them in any depth to be effective writing LightSwitch applications. For example, LightSwitch generates Silverlight in the application automatically, and you don't have to know anything about Silverlight or XAML. Unless, perhaps, you want to develop a custom shell, which is one of the ways to extend and customize a LightSwitch application.
The Right Kind of Application
All this begs the question, what kind of application is right for LightSwitch? Why would any developer or power user want to use a constrained version of Visual Studio? LightSwitch is ideal for forms-over-data applications, where the purpose of the application is to provide a user interface to view, insert, and update data in a data store. Admittedly, this is a bit of an application niche, but it's arguably a huge niche. LightSwitch provides all the infrastructure for all the common requirements for such an application, so that you don't need to write code to access data storage and manage the UI, and it provides a framework for implementing business logic. Figure 1 shows the LightSwitch UI at runtime. Essential features like searching and sorting are part of the UI by default, and LightSwitch supports strong security using either Windows or forms authentication. The bottom line is that you can focus on the custom features of each application without spending any time on the infrastructure.
Figure 1: A typical UI screen in LightSwitch, with some customizations for the particular data
Microsoft touts how you can write LightSwitch applications with little or no code, but I suspect that most nontrivial applications will require at least some custom code. The good news is that the code you'll need to write is the interesting custom stuff, not the repetitive infrastructure code such as for data access.
The best advice I've seen about when LightSwitch is the right or wrong tool for an application was on Microsoft's LightSwitch forum: "The rule of thumb I use is that LightSwitch is not the right tool for the job when the UI is the point of the application." For applications such as inventory control, asset management, data consolidation from multiple sources, and so on, the UI isn't the focus of the application. Instead, the application exists to process data and render it in the UI to the user. It is those applications that are perfect for LightSwitch. When you think about it, most effective Access and Excel applications also fit the description of being ideal for LightSwitch. Anything that doesn't process data and display it to the user would be better developed using some other application type using Visual Studio.
Real-World Applications
One of my clients has a membership website that contains some pretty valuable content, and membership isn't cheap. The company has various partner organizations that can license the content in a variety of ways, and my client is extremely creative in figuring out new ways to make money from it. One of the licensing schemes they use is to allow access by IP address, so that when a user navigates to the site from one of the allowed IP addresses they are automatically redirected to the member content without having to log in. This form of licensing isn't right for every partner, but for those it works for it has been wildly successful.
One of the challenges of this IP-based access is maintaining each organization's valid IP address ranges. Some use a single external IP address for the entire local network, whereas others have individual addresses for each computer, and there are lots of variations between those two extremes. Complicating things is that the IP addresses change more often than we expected. So my client has to have an easy way to maintain each organization's information and IP address ranges. It turns out that LightSwitch was perfect for this maintenance application. Figure 1 shows the user interface, showing the screen that lists the organizations, some of their details, and a tabbed table in the lower right to show the current IP ranges for the selected organization and a log of all logins to date.
LightSwitch uses a hierarchical screen designer that lets you place controls on each form in the application. The designer for my client's Organizations List Detail screen is shown in Figure 2, showing a portion of the overall screen design. LightSwitch includes various Silverlight controls out of the box, and you can use others from Microsoft, vendors, and those you build yourself—one of the ways you can extend the LightSwitch UI. Notice that you don't have complete control over form design unless you create a custom application template. Instead, LightSwitch organizes the form based on a row and grid layout. But it does provide controls such as Rows Layout and Columns layout, which give you lots of flexibility in using screen real estate.
A nice touch is that when you run the application from the LightSwitch IDE, you can use the Design Screen button, shown in the upper-right corner of Figure 1, to switch to a runtime version of the screen designer and make changes. This places the application in customization mode, shown in Figure 3, which provides access to the control hierarchy, a properties window for the selected control, and a preview pane in the upper right so that you can immediately see how the changes affect the screen. This is just one of many features in LightSwitch that make it easy to develop an application.
One of the harder parts of this IP access-manager application was to make sure that the user entered only valid IP addresses and ranges, including its form (the usual IPv4 form like 67.208.32.97) and excluded invalid IP addresses according to the specification (such as 127.0.0.1, which can't be an external address) and ranges (so that the user doesn't enter a range with hundreds of thousands of IP addresses). Because of how the IP-based access works on the website, there can be no duplicate IP addresses or overlapping ranges.
LightSwitch includes strong support for data validation. For the simple data types, you can set properties in the database designer that constrain each field in an entity. For example, for strings you can specify whether the string is nullable or if it allows an empty string. For integers, you can specify whether it is required and set a minimum and maximum value. LightSwitch also includes semantic types such as EmailAddress and PhoneNumber with support for display formats and validation specific to those types of data.
But our requirements for the IP address ranges fall way outside LightSwitch's capabilities. This is a situation when we needed to get our hands dirty and build custom validation in code. We had to do this at two levels because of the data design. After much discussion, the details of which I won't bore you with here, we stored the component parts of the low and high address of each IP range rather than as full strings for each address. Then we included some calculated fields to return each full address as a string, as well as return a count of addresses in each range. Figure 4 shows the final schema for the IPRange entity, where you can see the IP1Low, IP2Low, IP3Low, and IP4Low fields with the component parts of the IP address at the low end of the range and corresponding fields for the high address range.
This means that we had to implement validation both at the field level to make sure that each component was in the range of either zero or 1 to 255 and at the entity level to be sure that each IP address is valid. Figure 5 shows a portion of the field-level validation code from IPRange.cs file associated with the IPRange entity. For each field that is out of range, the code adds a property error with a message that will appear on the form when the user attempts to save invalid data. All of the infrastructure to provide the code with the results parameter, the current value of each field, and the AddPropertyError method are built into LightSwitch. You just have to know how to use them.
The entity-level validation code to make sure that the entire IP address is valid is pretty gnarly. Because this code has to use multiple fields in IPRange to validate the address, the code has to go into the IPAccessDBDataService.cs code file, where you can create entity error messages. Figure 6 includes a sample of this code, showing how it makes sure that the low address is less than or equal to the high address based on their integer values (IP2Integer is a custom support method in the same code file that converts a full string IP address into its integer value) and that the address isn't one of the many addresses that are invalid for use external to the network. (You can get all the gory details in the Internet Engineering Task Force's RFC 5735 document.)
At this point we're only covering IPv4, but we will soon have to update the code for IPv6 when it becomes more widely deployed. The code also includes a code block at the end to make sure that the IP address range doesn't overlap an existing range in the database. This latter code is a bit inefficient, but it works for now.
It turns out that even though we had to write some gnarly validation code, LightSwitch had all the features we needed to implement the application. The environment provides plenty of events and other code points where you can write custom code to do just about anything you need to do for this kind of forms-over-data application that LightSwitch is so ideally suited for.
One of the interesting features of LightSwitch, made possible because its user interfaces are implemented using Silverlight, is that you can deploy an application either to a desktop or to the web. On the desktop, it functions as a regular Windows application, and on the web it's hosted in a web browser. You can further deploy the database and middle tiers to different servers, giving you a true multi-tier application. Figure 7 shows the various deployment options under the Application Type property page for the IPAccessMgr application, with the defaults for installing the application entirely on the user's computer.
The Application Server section of the page shown in Figure 7 is where things get sticky. As you can see, you have the option of running all application services on the end user's machine or hosting them on another machine that is running Microsoft IIS or using Windows Azure. As soon as you want to move beyond everything hosted on the user's machine, you've moved out of the realm of possibility for a power user to deploy the application: A system admin will have to be involved. That's probably all for the best, but the documented system requirements for servers hosting LightSwitch are long and complicated, even for someone who knows what they are doing. Nonetheless, it is pretty amazing that LightSwitch makes so many options available. Best of all, the application is already architected for any of these deployment scenarios.
It seems highly unlikely to me that an existing Silverlight or ASP.NET developer will turn to LightSwitch to develop web applications, since you really have no control or access to the underlying Silverlight code. It is not intended to be an alternative way to develop Silverlight applications. But if you can live with its constraints, LightSwitch remains a fine way to create the kinds of data applications it is intended for.
Once you've explored LightSwitch and have seen all that it can and can't—and won't—do, the inevitable question is whether it really is a viable option for any but a small niche of professional developers and power users. Microsoft is marketing LightSwitch to both groups: to power users as a better, more scalable alternative to Excel and Access, and to professional developers as a quick and easy way to pound out forms-over-data applications. As purportedly a member of the latter group, I can easily foresee building more applications for clients using LightSwitch, when its constraints, mild as they are, are acceptable. As the IPAccessMgr application demonstrated, LightSwitch has plenty of ways to extend and customize what it does, and we were able to happily live with the technology choices Microsoft made for the tool. From this perspective, the LightSwitch team did an amazing job of creating a tool that is as comprehensive and productive as it is.
Whether LightSwitch will appeal to power users—those using Excel and Access now—is another matter. The IDE certainly helps create applications without needing to know too much about application architecture and things like Silverlight, WCF RIA services, or even databases. But there are two areas that have the potential to cause problems. The first is the database's design, if the application is not built to run against an existing database. Even using the LightSwitch data-design tools, there are plenty of potential problems with putting together a usable data schema that is easy to query and filter. But I suppose this is no different from potential issues designing an Access database for use in an application.
The other area with the potential for problems is the need for custom code. LightSwitch supports both VB and C#, either of which is a substantial step up from VBA that is embedded in Office applications. A user also has to get used to the event model in LightSwitch and learn the objects available to perform various actions as well as figure out the appropriate place to put code among the many options. It isn't the do-anything-anywhere environment of the full editions of Visual Studio, but it's a big step up from writing code in Excel or Access. This is far from an insurmountable problem, but it is certainly a hurdle. On the other hand, I'm sure that Microsoft will learn from users' early experiences with LightSwitch and over time make the product even easier to use.
It also doesn't seem that Microsoft is yet marketing the product correctly to target power users. By making LightSwitch a member of the Visual Studio family of products and, at least initially, making it available on developer-focused MSDN, the company seems to be primarily targeting professional developers at the moment. They have produced a detailed feature-by-feature comparison of LightSwitch and Visual Studio 2010 Professional, but I have yet to find similar comparisons with Excel and Access. If Microsoft wants to move power users from those products to LightSwitch, they'll need to provide a compelling case to switch. If they made LightSwitch available as part of Office, that would change everything. Only time will tell if LightSwitch gains traction with power users.
Nevertheless, this first release of LightSwitch is ideally suited to its targeted niche of applications, where data is king and the point of the application is not the UI. It is a remarkably complete product, one that almost certainly will grow into its targeted niche and ingratiate itself with its target audience. One good sign for LightSwitch is that component vendors are starting to release products specifically for use with LightSwitch, including Telerik, ComponentOne, DevExpress, and Infragistics. Support from third parties has always been a good sign for Microsoft products.
Figure 2: LightSwitch screen designer, showing the hierarchy of controls on the screen
Figure 3: LightSwitch runtime screen designer, which lets you dynamically make changes and immediately see them in effect
Figure 4: LightSwitch Data Designer, showing the schema for the IPRange entity
LightSwitch on the Web
Figure 7: LightSwitch deployment options as displayed in the Application Type project properties page
Is LightSwitch the Right Product?
