One of the Holy Grails of application development has been to allow a businessperson to build his or her own application without needing a professional programmer. Over the years, numerous attempts at this goal have achieved varied levels of success. A few have survived, most have sunk into oblivion.
Microsoft's latest attempt at this is Visual Studio LightSwitch, now in its first beta test. LightSwitch uses several technologies to generate applications that connect with databases. It can run on a desktop or in a web browser, and it can use up to three application layers: client tier, middle tier and data access.
The technologies used are quite sophisticated. Silverlight 4.0 is a rich Internet application (RIA) environment that can display screens in a web browser or on a desktop, and it hosts a subset of .Net Framework 4.0. WCF (Windows Communication Foundation) RIA services allow Silverlight applications to communicate. An entity-relationship model controls the data services. (See the LightSwitch architecture diagram below.)
LightSwitch screens run in three layers of objects. A screen object encapsulates the data and business logic. A screen layout defines the logical layout of objects on the screen. And a visual tree contains physical Silverlight controls bound to the logical objects in the layout.
In a conventional Silverlight application, or in almost any conventional application built in Visual Studio, the user works directly with the controls and layout and writes or generates a file that defines the visual layout and data bindings. For Silverlight and WPF (Windows Presentation Foundation), that file is in XAML. The Silverlight and WPF designers in Visual Studio 2010 offer two synchronised panes of XAML code and visuals.
LightSwitch can create two-tier and three-tier desktop and web applications against SQL Server and other data sources using Silverlight 4 and WCF RIA Services.
In a LightSwitch application, the developer never sees any XAML: The visual tree is generated on the fly from the screen layout. This insulates the developer from the almost Kabalistic complexity of XAML, at the cost of adding a CPU-intensive setup step that must run after every design change and during the application's runtime initialisation.