Code Focused

Is Visual Studio LightSwitch the New Access?

The LightSwitch RAD platform generates apps with "no coding required." What's in it for you? .NET apps that are easier to maintain and extensions built on the Managed Extensibility Framework.

• By Joe Kunk
• 05/01/2011

Microsoft publicly released beta 2 of LightSwitch, code-named "Kitty Hawk," in March. The technology is designed to make building line-of-business (LOB) applications easier through pre-built templates and custom business data types, with the ability to deploy to the desktop, the Web and the cloud. LightSwitch beta 2 has better performance and introduces an auto-complete control, flexible layout controls, an Excel-like grid, unique constraints for fields, an "all users" windows authorization level, support for custom data sources, the ability to deploy to Windows Azure and more. Before we look at the solution, let's take a look at the problem it's intended to solve.

Departmental App Attack
In an all-too-familiar scenario, you receive a critical support request from an LOB department to fix issues with a Microsoft Access application. That application began as a simple collection of forms with some reports. It has since morphed into a business-critical application straining under the weight of an increasing user count, stricter security requirements, interface needs, increasingly complex business rules and the need to expose the data via the Internet. These issues can manifest and result in data corruption, ever-slower queries, unauthorized access to app features and complex multitable macros. It's often difficult to get all of the users out of the Access database to do a Compact and Repair.

As a corporate developer or external consultant, you're presented with a collection of tables, temporary tables, macros, Visual Basic for Applications (VBA) routines, forms and reports that don't easily translate into the professional development environment of the Microsoft .NET Framework and SQL Server. When this happens, you're faced with essentially two choices:

• Upsize the data storage to SQL Server and keep the front-end in Access; address any remaining performance or security issues.
• Rewrite the application in .NET with a SQL Server back-end.

Neither choice can be considered a convenient migration path from Microsoft Access. Visual FoxPro is another tool often used by non-professional programmers that can create a similar situation. To a lesser degree, similar departmental application issues can occur with Excel workbooks developed by technically skilled end users.

This is not to say that all departmental apps should be strictly banned. IT departments will always have backlog, and department staff need a way to resolve their automation issues when they can't get priority with corporate development.

Bring Departmental Apps into .NET
LightSwitch is targeted to provide a tool for non-professional programmers to develop forms-over-data departmental applications that are both easy to use and corporate-development friendly. Don't confuse LightSwitch with the recently released WebMatrix product. WebMatrix makes it easy to create new Web sites or use the Microsoft Web Application Gallery to customize ASP.NET and PHP open source applications. LightSwitch is an LOB development tool that can integrate data from multiple sources and is purely a .NET Framework-based platform.

This application generator can be used to better address many common business automation needs for which Access might otherwise have been used. It provides simplified development through screen templates (Figure 1), a user-friendly table designer with business data types (Figure 2) and an interactive screen designer. LightSwitch applications can be easily deployed to the desktop, the Web or Windows Azure. Note that LightSwitch beta 2 comes with a Go Live license and can be considered for production applications.

[Click on image for larger view.]

Figure 1. The LightSwitch Add New Screen dialog.

LightSwitch runs on the .NET Framework and uses the Visual Studio project structure. Custom code is written in C# or Visual Basic rather than VBA. Both languages provide full access to the capabilities of the LightSwitch environment.

For example, Visual Basic can be used to easily extend database field behavior. Consider the need for an uppercase-only database string field. There's no force-uppercase property in the table designer (shown in Figure 2), but you can easily add that behavior by clicking on the Write Code button and choosing the Field1_Changed event. LightSwitch presents a blank method. Adding the highlighted single line of code Field1 = Field1.ToUpper() will ensure that the contents of that field are converted to uppercase whenever the user edits the field on any screen in the application:

[Click on image for larger view.]

Figure 2. The LightSwitch table designer.

NamespaceLightSwitchApplication
     PublicClassCodeSample
          PrivateSub Field1_Changed()
               Field1 = Field1.ToUpper()
          EndSub
     EndClass
EndNamespace

LightSwitch can participate in source code control via the integrated Visual Studio Team Edition Explorer. It uses SQL Server Express for its local data store at design time; deployed applications can use SQL Server Express, SQL Server or SQL Azure. If you have sufficient permissions via the data connection, you can create tables on the remote data source via the LightSwitch data editor.

The LightSwitch UI is presented in Silverlight 4 and architecturally follows the Model-View-ViewModel (MVVM) pattern. MVVM provides the ability to do effective unit testing through separation of concerns. The Model supplies the data for the application, the View provides the UI and the View-Model serves as the link between them. Note that, due to the MVVM architecture, application code can't directly access the Model (data layer) from the screen (View). More information on the MVVM pattern can be found in the VSM cover story, "6 Tips of Separation: Take ViewModel for a Spin and Test Your Silverlight Apps" (April 2011).

A departmental developer can install LightSwitch without the need for Visual Studio. For users of Visual Studio 2010 Professional (or higher), install LightSwitch but note that the Visual Studio 2010 SP1 update is a prerequisite. The LightSwitch runtime and LightSwitch project templates will become available within Visual Studio 2010 after installation. Applications developed in the standalone LightSwitch designer can then be opened in Visual Studio.

Extending LightSwitch
As a new product, the LightSwitch team is focused on building core functionality, and it's reasonable to expect that to be fully productive, some custom extensions will need to be written to fill the gaps that are inevitable in a first-generation product.

Fortunately, custom extensions can be uploaded to the Visual Studio Gallery and shared with other developers, so useful extensions should appear rapidly.

Custom extensions can be written in either C# or Visual Basic with Visual Studio 2010 Professional (or higher). Extensions provide a design-time experience, runtime experience or both. Multiple extensions can be combined in an application. The six available extensibility points for LightSwitch are:

• Business Type
• Control
• Custom Data Source
• Screen Templates
• Shell
• Theme

Business Types are custom data types that appear in Visual Studio for the first time in LightSwitch. They incorporate validation rules, data formats and the data value under a business-friendly alias. Native business types in LightSwitch include Email Address, Image, Money and Phone Number.

Business Types are validated on the client in order to provide immediate feedback to the user. If the client validations pass, the business types are then validated again upon the server to ensure clean data and apply any additional validations that may require server interaction. Custom Business Types will be shown among the available data types in the table designer.

The Control extension is essentially a Silverlight control configured for the LightSwitch environment. A description of the supported UI control types is shown in Table 1.

Custom UI Controls are selected by choosing "Custom Control" in the screen designer.

LightSwitch beta 2 natively supports data access to SQL Azure, SharePoint 2010 lists, SQL Server Express, SQL Server, the Entity Framework Provider and WCF RIA Services. Any other data source needed by a LightSwitch application must be wrapped in a WCF RIA Services DomainService. Custom Data Sources can be consumed by choosing the "WCF RIA Service" Data Source Type option of the Attach Data Source Wizard.

Screen Templates provide a stencil or pattern for the layout of controls on a screen. The templates are copied into the application when used and not linked to the source template. Thus, the source templates can be modified or removed in the LightSwitch visual designer without affecting screens that have already used the template. Custom screen templates will appear in the list of available Screen Templates in the Add New Screen dialog.

The Shell represents the look and feel of the LightSwitch application.

It's made up of three parts: the Navigation Pane on the left, the Command Pane on the top and the Active Screen page in the lower-right area that comprises the majority of the screen. The locations can be changed and reshaped by the Shell extension; for instance, the Navigation Pane can be shown at the right or bottom of the screen, if desired. A custom Shell can be selected in the General Properties tab of the Project property pages, as shown in Figure 3.

[Click on image for larger view.]

Figure 3. Shell and Theme selection.

A Theme is a color and font palette organized as a dictionary collection. The keys are the same as the ones used for the default built-in Shell and Theme, and in this way, they replace the existing look. Unique keys for a custom Shell can be defined, but you should always expose the built-in keys at a minimum in addition to any custom keys. A custom Theme can be selected in the General Properties tab of the Project property pages.

For example, an UpperCase Business Type extension could be created that would error unless all the alphabetic characters entered in the field are uppercase. While defining a Business Type extension requires significantly more coding, it would have the advantage of being available as a data type for use within any table definition.

Packaging LightSwitch Extensions
Once you've completed development of one or more extensions, you'll need a way to distribute them to the developer for use.

LightSwitch extensions are packaged into an .LsPkg format, which is then enclosed in a .vsix file. Like Silverlight .xap files, you can rename .LsPkg files with the .zip file extension and examine the contents. To be identified as a LightSwitch package, the .vsix package manifest must be marked as "VSLS" under "Additional Visual Studio Products" in the "Supported VS Editions" setting of the manifest. This will be set automatically for you if you use the VSLS Extensibility project types in Visual Studio 2010.

LightSwitch .vsix files can be installed on a PC with LightSwitch by downloading and executing them, or from the Visual Studio Online Gallery with the Visual Studio Extension Manager. To use a custom extension within LightSwitch, select the extension from the Extensions tab of the application's Properties page.

Is LightSwitch the New Access?
How does LightSwitch stack up as an alternative to departmental development tools such as Microsoft Access or Visual FoxPro? To be fair, LightSwitch is a beta 2 version at the time of this writing and will gain many important features in the future.

In its current form, LightSwitch excels in some areas:

• It can deploy to the desktop, a Web site or SQL Azure as a deployment stage choice.
• It can easily consume data provided by WCF RIA Services.
• The LightSwitch environment has clearly defined extension points for enhanced functionality or appearance.
• LightSwitch applications can run on any platform that fully supports the Silverlight 4 runtime. The technology currently has some limitations:
• Microsoft Access is a full Windows client application. LightSwitch Web applications run in the security sandbox of the browser and, even when deployed as a Windows application, have limitations on what can be run or accessed in the local environment.
• LightSwitch doesn't have a native report designer or reporting model. The LightSwitch Suite of Controls project provides a LightSwitch control extension that hosts the page generated from Reporting Services for full Web reporting functionality.
• LightSwitch does not deploy to mobiles devices such as Windows Phone 7.

The need for departmental applications simply will never go away. Users will always find a way to build what they need when faced with long delays from the corporate development staff. The pain comes when the departmental application "hits the wall" and IT is asked to maintain it, or worse, extend it. In that situation, IT will be much better off when presented with an application developed in LightSwitch versus the other possibilities. Inheriting an application built with LightSwitch means inheriting a .NET-based application, built on standard best practices such as n-tier architecture, data in SQL Server, proper data architecture, validation in the appropriate tiers and so on. IT departments should closely evaluate LightSwitch and consider training and supporting departmental developers in its use. The pain you save could be your own.

You can develop custom extensions to ease LightSwitch development within corporate standards. Extensions with wide appeal can be uploaded to the Visual Studio Gallery and shared with others.

With LightSwitch, Microsoft developed a completely new platform to bring .NET into Rapid Application Development. Should Microsoft instead have put its resources into a new version of Access, "Access.NET," that delivers the full suite of the familiar and easy-to-use Access development tools in a .NET environment?

What do you think? I invite you to use the comment section to share your thoughts and experiences.