InfoWorld preview: Visual Studio LightSwitch chases app dev Holy Grail
Beta 1 of Microsoft's LightSwitch shows promise as an easy-to-use development tool, but it doesn't seem to know its audience
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 initialization.
Not surprisingly, considering all that is going on behind the scenes, the LightSwitch designer feels molasses-in-January slow, even on a quad-core development machine with plenty of RAM and high-end graphics. While this may be a performance issue that can be fixed before the product ships, it is likely to be a persistent problem, at least until computer speeds double again.
When built for debugging, a LightSwitch application has a Customize Screen button in the upper-right corner of the runtime window (foreground).
Besides the benefit of shielding the developer from complexity, the LightSwitch architecture allows for an extremely convenient runtime customization facility. When you build a LightSwitch application for debugging, it has a Customize Screen button in the upper-right corner of the runtime window, which allows you to switch to a Customization Mode and edit the screen while the application is running. Alas, that too has a molasses-in-January feel.
LightSwitch's Customization Mode allows you to modify the screen while the application is running.
The database capabilities of LightSwitch are impressive. An ad-hoc table designer generates SQL Server tables. Existing SQL Server databases can be imported selectively, with relations intact. Relations can be added to imported tables. Entities can be imposed on existing fields; for example, a text field holding a phone number can be treated as a Phone Number entity, which supplies a runtime editor that knows about country codes and area codes.
But in the database area, too, LightSwitch doesn't quite deliver. While it can map an integer field to a fixed pop-up list of meanings, it can't yet follow a relation and map the integer foreign key to the contents of the related table. In other words, I can tell LightSwitch that 0 is New York, 1 is London, and 2 is Tokyo, but I can't point it at a database table that lists the cities of the world.