The announcement of Visual Studio LightSwitch this week has generated a lot of discussion, and as expected a number of questions about “what is LightSwitch really building under the covers?”. To help shed some light on that (sorry, couldn’t resist) we’re putting together a blog series that takes a more in depth look at the Anatomy of a LightSwitch application. We’ll start with this high-level architectural overview and then drill into each architectural layer and other specific topics over the coming weeks.
Here’s an outline of topics we’re thinking about:
- The Anatomy of a LightSwitch Application – Architecture Overview
- The Anatomy of a LightSwitch Application – The Presentation Tier
- The Anatomy of a LightSwitch Application – The Logic Tier
- The Anatomy of a LightSwitch Application – Data Access and Storage
(UPDATE: In Visual Studio 2012 (LightSwitch v2) we have updated the middle-tier architecture to use OData Services. See: LightSwitch Architecture: OData)
(UPDATE: In Visual Studio 2012 Update 2 (LightSwitch v3) we have added an additional client option, HTML5. See The LightSwitch HTML Client: An Architectural Overview)
With that, let’s get started…
Microsoft Visual Studio LightSwitch applications are built on a classic three-tier architecture. Each tier runs independently of the others and performs a specific role in the application. The presentation tier is responsible for human interaction with the application. Its primary concern is data visualization and editing. The logic tier processes requests from a client to fetch data, update data, or to perform other operations. This tier’s primary role is to shield direct access to the data from unwanted or invalid reads and updates. This helps to ensure the long-term integrity and security of the data. The data storage tier is responsible for durable storage of the application data.
A typical three-tier application
Designing a new three-tier application from scratch can be difficult and complex. Each tier presents a myriad of technology choices and internal system design. Each has distinct deployment and manageability concerns. Each must handle communications with the adjacent tier, and ensure secure access from trusted sources.
LightSwitch removes the complexity of building a three-tier application by making specific technology choices for you. You concentrate on the business logic and not the plumbing.
When we map the specific technologies used in LightSwitch to this architecture you find that the LightSwitch presentation tier is a Silverlight 4.0 application. It can run as a Windows desktop application or hosted in a browser. The LightSwitch logic tier exposes a set of WCF RIA DomainServices running in ASP.NET 4.0. The logic tier process can be hosted locally (on the end-user’s machine), on an IIS server, or in a Windows Azure WebRole. A LightSwitch application’s primary application storage uses SQL Server or SQL Azure and can consume data from existing SharePoint 2010 lists, databases accessible via an Entity Framework provider, and custom build WCF RIA DomainServices.
A LightSwitch 1.0 three-tier application
As you can see, a LightSwitch application is built on top of existing .NET technologies and proven architectural design patterns.