Microsoft Lightswitch - Round 1 of testing.
In every company there is more demand for applications than there is ability to create those applications. In the past, a workgroup in a Microsoft shop might create their own workarounds the limits of IT resources by using tools such as Microsoft Excel, Access or even a little bit of VB.NET code.
Excel is great for simple reporting, charting and even light data tracking as a intermediate step before the main line of business applications. However it quickly runs against the wall if the data being worked with is more complex than a few tables and look-ups.
Once that wall is reached, Access provides a great stepping stone for data management and feeding Excel data for charting and reporting purposes. With a fairly simple parent/child linked forms, it allows going to the next level with data, unlocking the power of a full relational database.
Access, however, is "opinionated software" and it is challenging for non-programmers to make custom user interfaces that don't work the "Access Way". (It is possible to make completely custom experiences in Access, but it somewhat defeats the purpose of the provided form editors.)
Additionally, while .NET languages can talk to Access, it isn't the native experience. After working with C# for years, VBA is a painful step backwards. Finally, Access never did play well with the Internet, having some half-hearted web interface options that I have not seen deployed to production in any serious capacity.
Enter Microsoft LightSwitch. In many ways I now think of it as "Access for Intranet and Web". LightSwitch is opinionated software, like Access. It goes even farther than Access in that you can't edit the layout of a data page explicitly. Instead, the order of fields is specified and the layout engine takes care of the actual presentation.
This sounds incredibly limiting, but we just deployed our first LightSwitch application. The process of connecting to our SQL databases was easy and had some surprising benefits. Like many organizations we have multiple applications with distinct databases. Normally we use the "linked server" feature to allow cross database access to tables, but LightSwitch understands the concept of federated data access, going so far as allowing the definition of virtual foreign keys across data sources. This made making a cross database application actually easier than our tradition method.
More importantly, after building a quick prototype example I was able to hand the tool off to a non-programmer who was able to quickly put together new needed data access pages in just an afternoon. Best of all, the underlying programming environment is Visual Studio 2010 with C# or VB.NET, retaining all the benefits of the modern development environment.
The output from LightSwitch is a Silverlight application. It can be deployed as to websites (although the user of the application must have Silverlight installed, which isn't as common as Adobe's Flash, for example). For Intranets this is much easier to ensure. Alternatively, it can be deployed as a desktop application (which is nothing but a container for the Silverlight code, so Silverlight is still a requirement). I would have preferred a native Windows Presentation Framework (WPF) application, but it does ensure that all deployments have the same user experience.
Overall our initial experience has been good. The only thing I do see as a problem going forward is that LightSwitch does not seem to have a way to integrate existing .NET business logic modules. This makes sense in that POCO (Plain Old CLR Objects) business logic modules don't have a defined interface. I have seen some posts where people have usedWindows Communications Framework (WCF) to access business logic, but I have not tried this process yet.
Still, LightSwitch has a place in the toolbox for quick and dirty data access projects. I see it replacing Access in this role in our shop, if only because we can leverage our C# know-how and work with Federated databases far easier than any other tool. Recommended, with those noted caveat.