LightSwitch and the Enterprise
Recently, one of our customers asked some interesting questions regarding the use of LightSwitch (Microsoft’s modern Visual Studio-based RAD environment) within an enterprise environment. The fundamental question was how well LightSwitch applications fit within their model for enterprise applications. This post shares some of the ponderings that ensued…
DISCLAIMER: I do not work for the LightSwitch team at Microsoft and have limited knowledge of the internals of the tool or its roadmap. Please refer to resources at the bottom of this post for more LightSwitch resources.
What is LightSwitch?
History: Our customer had a Rapid Application Development (RAD) team as part of their organization; this team handles some of the custom development that didn’t make the cut for the enterprise development teams. These applications typically are important to a small audience or for a short time and don’t merit the investment that a full-blown enterprise application may require. Their RAD team currently uses Microsoft Access and SharePoint for basic CRUD, reporting and workflow applications and they were looking for a more modern alternative.
To answer the request, we demonstrated Visual Studio LightSwitch to members from both their RAD and enterprise development teams. LightSwitch is Microsoft’s modern RAD development tool. It is housed in Visual Studio and uses good design patterns on top of the Microsoft .NET platform. It is frequently viewed as the heir-apparent for shops using Microsoft Access as it provides more modern development, deployment and integration options but still supports a RAD approach.
Corporate UI Standards
Overall, LightSwitch demonstrated well with our client and built the interest that we’d expected. Why wouldn’t it? LightSwitch is a good fit for RAD teams. But their enterprise developers asked some interesting questions, including: “We use Bootstrap for our web development and user interface standards; can LightSwitch use Bootstrap?”
LightSwitch 2012 Update 2 can deploy Silverlight (client or browser-based) and HTML 5-based clients (including SharePoint and mobile devices). As a result, it seems possible that you could employ Bootstrap with LightSwitch but honestly I didn’t have a real answer. Instead, my teammate David Jung asked some of our internal experts and came up with this answer:
“The LightSwitch HTML Client controls are based on jQueryMobile. You can add bootstrap controls to a screen using Custom Controls and then create screen templates which are based on that. While this is technically possible it degrades the screen design experience and I am not sure whether I would recommend doing so. There might also be some conflicts arising between jQM and bootstrap. It seems like a lot of work and I wonder what the real underlying goal is. Would it be sufficient to restyle the jQM controls to look like bootstrap?”
Because the LightSwitch HTML client is based on jQueryMobile and not Bootstrap, it may be possible to achieve the desired use of Bootstrap, but doing so would greatly hinder LightSwitch RAD productivity. Instead, consider using the technologies inherent in LightSwitch (e.g., custom Themes and Shells using HTML/jQM/CSS or XAML) to achieve the look and feel of the corporate standards without trying to force-fit a different technology.
Integrating with Enterprise Services
I believe the bigger question from their enterprise developers involved how to integrate these streamlined RAD applications with the overall enterprise infrastructure. For the customer in question, this meant working with an Enterprise Service Bus (ESB) and utilizing a Contract-Driven methodology.
Out-of-the-box, LightSwitch can easily work with a variety of back-end technologies, including databases, SharePoint lists, OData Services and WCF RIA Services.
When you add one of these data sources to your project, LightSwitch automatically generates all the CRUD code to allow you to easily interact with that data source. The resulting code is automatically exposed as a backend OData services that your client applications can use. Using simple wizard-based mechanisms, LightSwitch can easily add a variety of screen types (e.g., Details, Search, List, Grid, custom) to the back end data sources.
So how does this fit into your enterprise? The answer is, it depends on your enterprise and your own standards. The customer in question asked how LightSwitch could leverage their Enterprise Service Bus (ESB) infrastructure. And although that isn’t enough information to actually answer the question, we can make some general assertions…
Generally, ESBs provide and consume a variety of endpoints with different serializations. If your ESB and standards support OData and/or WCF RIA Services, the integration can be very easy and is directly supported by LightSwitch. If you’re using a different technology such as XML/SOAP Web Services, the process can be more difficult.
Since the internals of LightSwitch use .NET (and in some cases JavaScript), you have a wide-open extensibility model. You can programmatically hook-in other services by simply writing a little code. Beth Massi has a nice post on how to call an XML web service from your .NET code from within LightSwitch. But the point to recognize is that this approach allows you to call out to other services, kick off workflows, and otherwise talk to other endpoints… But it doesn’t give you the full LightSwitch experience. That is, you can talk to other services but unless it is a supported LightSwitch data source, you can’t use the slick pre-built screens to quickly develop applications. You may be able to create a data source extension to handle your endpoint in a more graceful manner.
If you have existing service endpoints that aren’t compliant with the built-in LightSwitch formats and you need screen-level data integration, you may consider wrapping those services in something that LightSwitch can understand. This may allow the full LightSwitch experience but does require adding an extra layer.
One final question from this customer regarded their enterprise developers using Contract-Driven Design and whether LightSwitch can play nicely in that world. Again, that is a big question as “Contract-Driven Development” or design can represent a large somewhat ambiguous set of activities. If the question is whether LightSwitch can consume services authored using a Contract-Driven approach, the answer is “of course” (but pursuant to the limitations discussed above). If it is a question of whether LightSwitch is a Contract-Driven design/development tool, the answer is no. It is a RAD tool and the approaches are different. Since the LightSwitch server components are using .NET, you could add Contract notations to your code using tools such as Microsoft Research’s Code Contracts for .NET, but again, this is really trying to mix two vastly different approaches and you’re likely to cause more pain rather than solve more problems.
Conclusion
Although all enterprises are different and the questions asked above may not directly pertain to your organization, hopefully you see a pattern. LightSwitch is a powerful, flexible RAD platform making it easy to develop general CRUD line-of-business applications that can integrate with the rest of your enterprise technologies. That said, LightSwitch is not an enterprise development tool and is not suitable as a foundational technology in most enterprises. Continue to write your enterprise applications in .NET but feel free to use LightSwitch to integrate with your enterprise.
Resources
The following external links were explicitly referenced in this post or provide additional supporting information: