But because LightSwitch is built onto Visual Studio with all its underlying technologies, a tiny application written by a lone power user could be taken up by the IT department, enhanced and deployed using all the regular Visual Studio tools.

You hardly need to write any code by hand; LightSwitch generates a lot of clever VB.NET or C# code behind the scenes. Its use of MVVM means that the application is divided up into three tiers across six projects, and these tiers can be deployed on separate machines.
The presentation tier is created in Silverlight and will run either native on the client workstation or within a web browser on that client, while the business logic layer can either run on the client PC or in IIS7 on a server. The data layer runs on the server to target SQL Server tables, SharePoint lists or WCF RIA endpoints.
SQL Server Express 2005 and above will work fine for small ad hoc databases, but perhaps the most remarkable thing about LightSwitch is that you can move your whole application from a tiny platform such as SQL Server Express to SQL Azure running in the cloud with only a couple of mouse clicks. When you deploy the application you choose either two- or three-tier deployment, and point to the database server you want to use, whether that be a physical server or virtual SQL Azure.
Point LightSwitch at an existing SQL Server database and you can select all the tables in which you’re interested: it then reads their relationship information and builds a model of how the different entities are structured.
For instance, it sees that a customer has invoices, and those invoices have lines; it intelligently turns plural table names into singular entity names and can parse “camel-case” names such as InvoiceLines into more readable display names such as “Invoice Line”.
You can add extra calculated fields to LightSwitch data entities and extra relationships between entities even if these aren’t defined in the underlying database, and you can create relationships between entities in different databases or on other platforms – for example, between SQL Server and SharePoint.
LightSwitch supports extra data types such as phone number and email address, and when you apply them, extra validation and formatting is applied wherever they occur in the front-end input screens.
While you’re editing the entities you can rename fields, change their order to make them more logical, set some fields not to display by default, and choose which is the default summary field that’s shown in a list of these entities.
For instance, if you had a Person entity with GivenName and FamilyName fields, you could create a new calculated property called FullName, make it the first field displayed and the default summary field, so that any list of Persons always shows FullNames by default.
Screen design
Designing screens is easy and remarkably flexible. There’s no traditional screen design surface of the sort you’d see in Access or Windows Forms, so you don’t drag controls from toolbox, arrange them on a form and tie them to the data.
Designing screens is easy and remarkably flexible
Instead you start by choosing a template such as an editable grid, a list with details or a new data screen. Then you point the designer at the entities you want it to display. If you wanted a screen to allow the user to enter a new Invoice, you would select the New Data Screen template and tell it to use the Invoice entity and include the InvoiceLines.
LightSwitch then automatically creates the screen layout, with the relevant fields for the Invoice header at the top of the screen and a grid for InvoiceLines below it. These fields are shown as a tree structure for you to rearrange, alter properties and otherwise edit if you don’t think LightSwitch has it quite right.
Disclaimer: Some pages on this site may include an affiliate link. This does not effect our editorial in any way.