Microsoft Visual Studio LightSwitch: Clap on or Clap Off?
There are two types of developers.  For some developers, it is a craft: they carefully write (and hopefully follow) requirements documents, tests and/or study patterns. For these developers, the application is more about the careful design steps required to guarantee an application that works (and is maintainable) today and in the future. The other group of developers just want an application without the complexity of ALM, application plumbing and writing and rewriting CRUD logic. Preferably that they don't have to recreate next month when their manager adds to the scope of the application.
Microsoft Visual Studio LightSwitch is targeted squarely at the second group. LightSwitch is - for most intents - a "forms over data" line of business development tool. Microsoft is pretty fast to try to separate it from Access. However, I find the distinction a little flat:
There have been a lot of questions about how LightSwitch relates to Microsoft Access. Microsoft Access is for business end users who want to report, track, and share information across groups either from their desktop or, if desired, SharePoint. LightSwitch is part of the Visual Studio family and is primarily targeted at developers; it is not an Access replacement. One of the key differences you will run into is when you start to work on your coding assets. LightSwitch uses the full Visual Studio shell and editor and gives you direct access to the .NET Framework. Note that for Beta 1 LightSwitch does not yet attach to Access database files but this feature will be added before the product ships. -- Jason Zander (Corporate VP, Microsoft)
See the difference? Access == end users, LightSwitch == developers. Keep this in mind as we look further.
The first big distinction between LightSwitch and Access (or tools like it) is that you're sitting squarely inside a tool looking just like Microsoft Visual Studio 2010 to create your apps:
Now, I have to admit being a little surprised that the first choice is for programming language, especially for a tool that pushes "limited coding", but it will be used later if you do actually write some code in your application.
I also have a few issues with the opening screen for the application designer:
Holy Tabula Rasa, Batman! That's it? No, "Here are a few suggestions/samples to get you going? Pick a few canned solution templates?"
Building an application with LightSwitch
For a first look, let's create a few tables for an inventory application for an art store. Here you're presented with a fairly standard table designer. I do have to admit that despite my griping about LightSwitch so far, I do like the relationship window (see below). It makes the relationships between the tables perfectly clear, including what happens if you try to delete the parent entries (cascade delete is also available).
Once your tables are in place, you can start laying out screens. LightSwitch comes with a number of stock screen types, and I imagine that more can be added through the extensibility model. The most common CRUD screen types seem to be present.
Ah, the screen designer. I have to admit, I've been spoiled by WYSIWYG screen designers for ... uhm ... decades now? I can see what they were trying to do, but I really can't generate much love for it. I'm hoping that at least some sort of preview shows up before launch. It does seem relatively flexible, assuming you can keep track of all the nesting using the tree view. In addition to all the expected controls, it was nice to see a few controls specific to data types, such as editors for phone numbers, email addresses, images, and pick lists (for lookup data).
The applications you create with LightSwitch run in your choice of Silverlight (two-tier), Silverlight (three-tier, using RIA Services to communicate with the Web server) or Silverlight (in a browser, with RIA Services to communicate with the Web server). With the desktop versions, the Silverlight application is presented in a container application that shows the list of screens you've created (with the exception of Details screens, which are used in the other screens). As you open new screens, they arrange across the application in separate tabs, so you can always find what you were working on earlier (although I'd like better names on the tabs, perhaps the summary field of the entry). You can edit the toolbar to add more buttons as needed. Validation is added to the fields, based on the settings you've applied earlier, and it can be customized just for the fields.
Notice the "Customize Screen" button in the top right. This brings up the same editor you used earlier to define the screen, allowing end users to break edit the screen. It does look like it's probably not the final version of the feature however (the button looks tacked on).
Beyond the basics, there are two main extensibility models:
- You can add code at specific points in the process. These are the usual BeforeX, AfterX style event handlers, along with a number of security related events (CanEditX, CanRunX, etc.). These are written in the language chosen when creating the project.
- Create new Silverlight extensions and include them in the project. This is where most of the control vendors will be coming in, allowing for the creation of new controls.
A few other random thoughts as I went through Beta 1:
Oh, you still want an answer? Well, the choices here are export to Excel (by default all list and search screens get this) and do something, write yourself something in Silverlight, or buy a solution. I'm sure that something will come along.
- Other database access
You can connect to other data sources from LightSwitch. For other databases, as long as there is an Entity Framework provider installed, you can access your data. In addition, it can connect to SharePoint tables or RIA Services to receive and edit data. This does bring up the possibility of mashing up data from a number of sources into your application.
It's a Beta, so it wouldn't really be fair. Having said that, both the two tier and three tier applications seem acceptable. Start-up time is poor, but I think that of most Silverlight applications.
- Handing the basic application off to a ‘professional' developer for completion
I've heard this bandied about by a few of the people defending the application: that you can "Once you've got the basic application, you can give it to an advanced dev to complete." I'm not sure where they got this. Short of the above extensibility, there seem to be no clean hooks available to edit the generated Silverlight, RIA Services, or the Entity Framework model I think is hidden within the DLL.
In short, LightSwitch is definitely a 1.0 product, and an early Beta of one at that. It's functional, a little rough, but promising. It remains to be seen if it follows other rough products like Hailstorm, Quadrant, or J# or will mature and it become as successful as Visual Basic and Access.
 Of course that is a generalization. Everyone knows that developers are as unique (and delicate) as snowflakes.
 Visual Studio LightSwitch can co-exist with Microsoft Visual Studio 2010 Express products. LightSwitch can also be installed as a standalone product. However, when installed on a machine that already has a Visual Studio 2010 installation (read; Visual Studio 2010 Professional and above), Visual Studio provides LightSwitch project templates similar to that of Windows Phone 7 and Windows Azure development tools.
 Really, how many table designers do we need?
 I'll forgive them the grammatical errors: it is only Beta 1 after all.