Inside Visual Studio LightSwitch
Microsoft Visual Studio LightSwitch uses a model-centric architecture for defining, building, and executing a 3-tier LightSwitch application. A model-centric architecture uses models to describe the structure and semantics of an end-to-end application. The applications that you build with LightSwitch have a traditional N-tier architecture. In this article we discuss the LightSwitch model-centric approach and the main elements of a LightSwitch model. We’ll also look at the runtime architecture tiers (presentation, service, and data) and how they relate to the model. Model-centric Architecture Models sit at the center of the LightSwitch design time and runtime architecture. We will discuss several elements of the LightSwitch model-centric architecture: building blocks, models, designers, runtime, APIs and extensions. Building blocks are the core concepts or vocabulary used to describe an application. Some of the LightSwitch building blocks include: - EntityType and Query: describes the shape of data and queries against that data. Example of entity types are Customer, PurchaseOrder and ExchangeRate. Examples of queries are SalesByMonth and ActiveCustomers.
- Screen and Control: describes a screen, the controls it contains and its visual layout. Examples of screens are CustomerScreen and OrderEntry.
Building blocks have relationships to each other as well, with, for example, screens binding to queries that return entities. Creating a project in LightSwitch creates a model, which contains a description of the application in terms of building blocks. The developer uses LightSwitch to create a model containing screens, entities, queries and so forth that describe the application. Thus models are the core construct used to build applications, not code. The LightSwitch development environment contains a set of designers that know how to create models according to the building blocks, such as the screen, query and entity designers. Thus we see that many of the building blocks are top-level concepts in the LightSwitch development environment, while others are created on the developer’s behalf. Models are just data without a runtime to give them behavior. The LightSwitch runtime loads the application, authorizes access, renders screens, retrieves data, runs business logic and many other tasks. It reads the model to perform many functions. The LightSwitch runtime does most of its work by employing many other Microsoft technologies that are integrated together according to best architectural practices for building business applications. These include Silverlight for rendering and client logic, WCF for communications, ADO.NET Entity Framework for data access, ASP.NET for authentication and diagnostics and much more. This integrated set of functionality is one of the greatest benefits of the tool: selecting the right technologies for the job and combining them effectively takes a lot of time and expertise. While much can be done declaratively through modeling, coding is still important and LightSwitch provides APIs to do so. They can be divided into two kinds. The first are APIs for interacting with the runtime, such as to read or write data. The API also includes classes that are generated from model elements. For example, a Customer class is generated from a Customer entity, enabling business logic to be written against the Customer class. The runtime raises numerous events where business logic can be written. The runtime also provides numerous extension points, enabling the addition of new controls, data types, visual themes, screen templates and more. LightSwitch Application Model When you use LightSwitch to create a model, you’ll see top-level concepts in the designer like Data Sources and Screens. These concepts are grounded in the LightSwitch building blocks. Some of the building blocks are concrete and have direct expression in the design environment such as a screen. Some of the building blocks are more abstract and used only under-the-hood. Figure 1 shows some of the major LightSwitch building blocks. 
Figure 1: Major LightSwitch building blocks.The Application building block refers to the client, which is composed primarily of Screens. A screen has properties that describe the data that the screen works with. There are simple ScreenProperties and ScreenCollectionProperties that hold lists of entities. A screen property can be initialized from a Query. A Screen has access to all of the data sources in the application via an EntityContainerGroup, referred to at runtime as the DataWorkspace, which comprises a set of EntityContainers, where each EntityContainer is associated with a specific data source. A DataService defines the service tier and exposes data from a specific data source. A DataService implements an EntityContainer. The EntityContainer describes the shape of the data in the service. This is one of the under-the-hood concepts in LightSwitch. The designer defines an EntityContainer implicitly as you add elements to a data source. An EntityContainer has EntitySets and QueryOperations. An EntitySet is analogous to a database table. It is the logical location where instances of entities live. QueryOperations return a selection of entities from an EntitySet or from another QueryOperation. An EntityType represents a specific kind of business data. For example, a Customer, an Invoice, a Book or a TimeCardEntry. EntityTypes can have KeyProperties, EntityProperties, and NavigationProperties. KeyProperties are determined by the designer. A normal EntityProperty can store simple data values, or it can be a computed value that is not stored. NavigationProperties define links to related EntityTypes, for example, the Customer for an Order. EntityTypes are shared between the presentation and the service tier. The associated business logic (such as data validation) is executed identically on both tiers. |